From nobody Mon Mar 25 07:51:46 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 4V34rk6wJ0z5FZym; Mon, 25 Mar 2024 07:51:50 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from thyme.eden.le-Fay.ORG (THYME.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:107::10]) by mx1.freebsd.org (Postfix) with ESMTP id 4V34rj3jhsz4Yf8; Mon, 25 Mar 2024 07:51:49 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=le-fay.org header.s=thyme header.b=l+aaxptn; dmarc=none; spf=pass (mx1.freebsd.org: domain of lexi@le-fay.org designates 2001:8b0:aab5:107::10 as permitted sender) smtp.mailfrom=lexi@le-fay.org Received: from iris.eden.le-Fay.ORG (IRIS.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:106:3::6]) by thyme.eden.le-Fay.ORG (Postfix) with ESMTP id 6922E72; Mon, 25 Mar 2024 07:51:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=thyme; t=1711353105; bh=JaeayH90YSJ7HlSiF+afrKMNoK6DHoUj2SJvgAu8gTY=; h=Date:From:To:Subject:References:In-Reply-To; b=l+aaxptnxKWwIHj+XWYcYRdlUFnj3ROlBYkkqRnC1pvT4CSNuvmG0TdT6jZS7Wwfn hjl9zef1iXOhffQkTCG4C/AtW9qd/Ls4ViMxH76eIA7uRzmjcSXaqG9nwWMaQo5HVJ eB3cjHp+B+tyaIS756hzzEYqPVFAZJKTol/6pAnA= Received: from ilythia.eden.le-fay.org (ILYTHIA.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:106:3::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 863AE2C0418; Mon, 25 Mar 2024 07:51:46 +0000 (GMT) Date: Mon, 25 Mar 2024 07:51:46 +0000 From: Lexi Winter To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: after trivial update, 15.0 ARM64 system no longer boots Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jiWxeC+e7eKwX/aI" Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.50 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[le-fay.org:s=thyme]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2001:8b0:aab5:107::10]; RCVD_NO_TLS_LAST(0.10)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[le-fay.org:dkim]; ASN(0.00)[asn:20712, ipnet:2001:8b0::/32, country:GB]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2001:8b0:aab5:107::10:from]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[le-fay.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[le-fay.org:+] X-Rspamd-Queue-Id: 4V34rj3jhsz4Yf8 --jiWxeC+e7eKwX/aI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Lexi Winter: > i am not really an expert on either ARM64 in general or on the RPi > hardware in particular. could anyone suggest how i could debug this > problem, e.g. to get more information about why the system won't finish > booting? i dug into this a bit more, and to answer my own question: - the boot failure that prompted the question appears to be a bug related to mmc, i reported it as PR 277884 [0]. - part of the problem, that i realise i forgot to mention in my initial post, was that my USB keyboard wouldn't work, so i couldn't interrupt the loader to use boot -v / -s / etc. or to access kdb. this turned out to be an issue with the keyboard itself - a different keyboard worked fine. the keyboard *does* work fine in FreeBSD once it's booted, which is odd; it's some $5 Amazon special, so i assume it just implements USB badly. - even with the working keyboard, ctrl+alt+esc doesn't seem to work to break into kdb when the problem occurs. i'm not sure if i'm doing something wrong here or that key sequence doesn't work over USB, so i wanted to try it via a serial console instead, which led to... - i played around with USB OTG a bit to see if i could get a serial console that way. FreeBSD does support serial over the OTG port (via the USB-C 'power' connector) and it works as a terminal in /etc/ttys, but neither U-Boot nor FreeBSD seem to be able to use it as a system console, which is a bit disappointing. it would be nice if there was a way to get this working, because a serial console over USB would be very handy for working with these devices. - in the mean time, i ordered a DB-9 serial HAT that connects to the UART to debug this and future issues. once that arrives i can hopefully get some more info on the original problem. regards, lexi. [0] "RPi4: mmc broken with GENERIC-NODEBUG": https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277884 --jiWxeC+e7eKwX/aI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmYBLQ8ACgkQDHqbqZ41 x5kZbQv/cKotFS2k/fmGQbsAExgyRjNEgQzTtJaBCI+9vCD+sUHWsAN3e/x97ocy cY2xo3GRbQmczUgmGe3mezpzUx+nP8l3OVCaUbNqJG9oUmYugJw3zqbnKjxB3kB3 Rh3XTkZCiRq4z7rDDR8VHlT4X9Wj8BBkzbwaLDhLQL2e2imCTdCBZlAU+dO3Sqq5 C5efssUIJGoi9Olb6x+UYvOkEK7Nc+s/+OR8o6ck72lMwEp4EgpJJ448UbFszUyw N8RXfluZHwgicnb4UUXokZ3CZh6g1i/ne5HCvH6TJS/cU1wzYxY4OC7iqvJHuUR2 jo75UHyCFNxKqfApQ+NWd1fIRjlIZK6Vhjt/1+8YuORVayypATysEJ+3fMG/qYUg WDkK6q3UzE3TlDEYAlACSDoyzvRboF082/333UA9rEdDEc/3zbRMoEgcE7LZvP9l y9slzB/Hztno7DjwFIJrIQcLjQQM97xOP4TGle6Fdosc/V7v5d++aIuXNcHnyNfR hFk/x6Yf =Avvt -----END PGP SIGNATURE----- --jiWxeC+e7eKwX/aI-- From nobody Mon Mar 25 08:00:07 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 4V352N1yw8z5Fbpg for ; Mon, 25 Mar 2024 08:00:12 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V352N1XGcz4bBR; Mon, 25 Mar 2024 08:00:12 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711353612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=MX+cus6gUCbxL+VNFp9Cas07w1fca0TS3GyteCvCxk0=; b=sdcio5hH6DNA6sEJI7xVLM69GZirj7KSpkOT7kwAcc03mkg7WHYr+yJY/wIQ+dNS+EWLvv 2Sxn8UUk4xhXV4FrVnkMoypjMA/Z1CMdyVcThweKj4RM5HNYE7AqQtqMnFR5OmFv0AyM24 Daej3xVsnvI9/nrgXhc1L2RnCBwDhYj3T8m+/7BYOo3npPTH8BgpqpnDJuyOuosqfUfTUI sSl/Uwa14pAhot+Qootupc0sNk8UU0jdQ6MO2xYQgKe/Hcvu7/NREdH6/2MgnfFvbztWxC OGdJSOP/MchtBGz5W/X+wO2vVcS0tOD+lLevchh7rSInN88HT6fISIPHLRKowA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711353612; a=rsa-sha256; cv=none; b=MvsWonQ6R67l1D0ere/6pG3DKS/0vxbhK05eH+IvF/UP+lPMUOQY7kAmRauVk9BiSUJdCN Hazfsi7PmKwyqkZrADGs9/5Y63eylWH2ChrUGr53QOzKq/8Exbii8V2aSPjHrVHUYSnK6t WBN6F8g6fZZ/AvERwVi5572ICVpQclNt1NlCHaNJJSxY213wJA+dW1Eu+abk2VgyQq1iws zuZaBGKCyKMItV6pT2wgmmAoe90ijg4aWIUWBsS9JXt4/LOiQskeUHS8cHqzjsKXIk+4/9 4QBa/cOVUjTSpIqvUw0MWA1iNHVdzhxFaq0MUMLdfzLq2WOvvRn/niCxThHuYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711353612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=MX+cus6gUCbxL+VNFp9Cas07w1fca0TS3GyteCvCxk0=; b=Y2mJsP0bOybwBELYOIMKSULkG+64580CNsHnlwPY54fYl1f4lfBTE+7K9TousWmIT46jiV Pw4/u/k53Y0dalKypk6wCp7qggM68B62wAf51zDhdaJVbDmJXotXwXDjoWDnFs4RwpoQIl tofjgIz6T5GLuWproa/bmWPQ9nE2uU9GJAEExWtPKvJ7AIQ55OYeAug0UUigc8cS+KxL10 +5h33TAh9RxdnEwXv50iGXSyJdYTGM6keERM3RLAwFLGHP4ogQOIUfqC9+bPKywRRXu7UW i51kxNMLArY9xLT88c9sBPOPsjIFsaAl/FE8D1KSBElPIyZZATPXEcqO4lhUYA== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4V352M53fhzMrb; Mon, 25 Mar 2024 08:00:11 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 25 Mar 2024 01:00:07 -0700 From: Gleb Smirnoff To: current@freebsd.org, src-committers@freebsd.org Subject: March 2024 stabilization week Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi FreeBSD/main users & developers: This is an automated email to inform you that the March 2024 stabilization week started with FreeBSD/main at main-n268989-caccf6d3c008, which was tagged as main-stabweek-2024-Mar. The tag main-stabweek-2024-Mar has been published at https://github.com/glebius/FreeBSD/tags. Those who want to participate in the stabilization week are encouraged to update to the above revision/tag and test their systems. Developers are encouraged to avoid pushing new features to FreeBSD/main, but focus on bugfixes instead. The stabilization week runs up to Friday 18:00 UTC, but if there is consensus that any regressions discovered by participants have been fixed, it will end early. Once that happens, the advisory freeze of FreeBSD/main branch is thawed. -- Gleb Smirnoff From nobody Mon Mar 25 09:16:01 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 4V36jy5b3lz5Fjbm for ; Mon, 25 Mar 2024 09:16:06 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V36jx3GWzz4kq3 for ; Mon, 25 Mar 2024 09:16:05 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=NFOeSn8n; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-33ec7e38b84so2962147f8f.1 for ; Mon, 25 Mar 2024 02:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711358163; x=1711962963; darn=freebsd.org; h=autocrypt:subject:to:content-language:from:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Uitxpil5FFhSvRGwSB8fn1yjHy1Q+tmrrzNBqVuNzC0=; b=NFOeSn8nYr8pH8QiQow1j91p5hX8ap8TGPLKrtyA7YNJUFVsRq3QHysJkKAK1WMBtF F+aVYI8Xdmmdap44il3zAoZjzpWItZgqpmpxr/KpwO80MrrkUdZFMltTh03ShUlUaxQ/ AWk8b4dm010XDF0RmlXDOLPn9QOmO6oL4OAVxLYL5dq3uw1KbdaUXPWgsuX2TLvtpku3 Ao8K4a9SklUtBGHcw8fEtEVXOs4Ace3+p25Vk2CLE3VEuw/RKupYFCP6hwAeqxtrCAg3 cHUXRmtWOHTqpVktqUoxBlZy244BMUeJdqBx/KHazvAzSm3uRQlpEF3R94pJfOBp7lIB 8K3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711358163; x=1711962963; h=autocrypt:subject:to:content-language:from:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Uitxpil5FFhSvRGwSB8fn1yjHy1Q+tmrrzNBqVuNzC0=; b=ls0UxXmNBtvGg3gwpO/bow979XgNEFqfapH1KWCuEBOmTVkKfK8Zm//aCsC3BXK9j4 Zh2K+CbYBep8Dr1M2qefD/qs9T+hIC6lVdjmUJz/P0mFcNrlsiUyCof/NCjARHA8/sn2 B4loIwJ9irvifAr2oosxQAuzmSVqwyLUrNFhfnXVH+jxdkCkUdCPJhA0g3SHeUjpnnpu nhTXVsbXrzJiPoWVzAk2gZmE3qvzfgWHo5f8fofogChfgPMAYo7IArt+va77Rk2rqoTB vZTx2/dq4Btrl5Gifynvii2gKJOrRtS4Au61w6dDpiBqFfEYlMDx6L+JXqP/0dzD106i xAbw== X-Gm-Message-State: AOJu0Yx/Vo+8RqE/Xq0hJLLnNSJ86K0kU22GZhuwqVq7hu+cBi9yFFkr MqYkMTMUmG71EgbHlNClXnpUCN/Vj7NkQ3bXWzTMl9J5Ll9VTgUYNRTRkGILOsE= X-Google-Smtp-Source: AGHT+IE7RqEf6qtl6IPAFaPDrXrbfxNSqzfGtwvdIqyeEu090wJth1ww4+izKoUUI/CS1FXtN+xBXQ== X-Received: by 2002:a5d:5cc6:0:b0:33e:c521:7c33 with SMTP id cg6-20020a5d5cc6000000b0033ec5217c33mr3582855wrb.49.1711358162886; Mon, 25 Mar 2024 02:16:02 -0700 (PDT) Received: from [194.81.204.28] (oa-mowa-01-194.81.204.28.brighton.ac.uk. [194.81.204.28]) by smtp.gmail.com with ESMTPSA id cr1-20020a05600004e100b0033b48190e5esm8975528wrb.67.2024.03.25.02.16.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Mar 2024 02:16:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------GXZEcrSa0Jhf0C2FQUv6HGiB" Message-ID: <7cad1ab3-0db2-404b-8a9b-4f6ba24c512a@gmail.com> Date: Mon, 25 Mar 2024 09:16:01 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Graham Perrin Content-Language: en-GB To: FreeBSD-CURRENT Subject: CURRENT 220ee18f1964 memstick kernel panic, MacBookPro8,3 Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJimMMBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQLbHAQAJi998y42bEbq5HmABYovmAEtQj33YSUWyc9QRmAHpN8Er3lTKsgmZcVChB5Fu/d go2oYynDjlVpA7+wiSmg4AG78mOYbg/e19XMhrH0keDKqZXFkU+G7agR0mF09qvpQZ9MTJYZ 2u7FtytZK665UfipOdV8eGn2hFC/WynjUwEzKyryBgbbLAEbfOPeZNry4h2ZPWbtTvx/PE/V X3Vh2oGqYx69DCGz+0xEhy62ZKbkX5SL8LUf/1WViyCVzsHasFxmFxYPWIfBy8ayQ7xapz7M cSXSQyu4oDT4qh9eZiGP9/aAcZKHcV6t9y77JGhUJ/5O1sANKMa3YhgimE+Z86LHYa1IH774 PHj1nAXBwS+Cj/1l/NQoQcyjvOj8zuCsMJVaLMb6B46YsReP4+3yBLpyeBC//t6zWPbgAkWW VjROC0dXUAMTFpnA6NZe3UghG+Nc4fnCLGOhc2nyWFYHIaYV6Hv1ITFSem9DdeNnR1CFm1VM TJ7i7TuqYM+WZTkoUsTf4c46hS/ZNJZSCxh0s9yYr+BYk3XBbd+ElaZ1dJE6cuSVdw15+P2h DnprurxC4byl4YFkn+UAVvQsOgeq6aSHLOHX0weYu1OLoiPYsTdyGhne72+kDhEEdFD5aHdQ PFrbQIrqWLV0a04++0ZwGpNvXtgnWhDdAQJDwGsSSwbLzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmKYt7ACGwwFCQWjmoAACgkQt2dIb0oY1Av7qg//YjCZg8VXyMzXssgIQpROKKqh5V0UBSQl rM3tq4tWhyg0HVMugQj0Om+iNPsEEOGHkm6tyhHMzlKGpAc/l0iAM+8twIyg44Yo5+DcfFXr OMTbTw9T9jDsWOkOBksxy29iYhgpqpWdDBnhXvrJp/FNAiX8CfzrIOZeFPydDoEiKBEXAxfe a9o5J/JeVnZiUeoiFe7i68nZGsb4JxhPczNfqW12t0Ll5/ibjszg5BgjXiLao0KqbWNh4bS5 CVwH90Or+5qqWgzWPeBiuz+rN2QXE/V/fL44GEj1YKASCqmaiYRgjoRFubz1aq1wCXMXY3Iq d4525rscUgS7HBxbblnyTodUPaamN/2nSzcmE/Pkx8MApDSgZCIhs0RTAg+/AoX4HULV1rSE TQwMrBEQt84Tw5W5rHsvXKr4ZEsJUpbPLWYTISsp23nHR+vZtL/Ug+OWCmHC7X7D21xk/xVJ 4sA1RLJBKdCHtnyA4Unv/kNS1KVGxHnITVyw1a71QJADu4qsdtM5u6CyYUhqhM1oseWtV6j+ Qi8KC/G4C3AgZf06fe2fVl42z2grTabL4bC6FQXMwTX2dsm5NakWjUCmUL8uwsQE7ZA4zKxo EYI1YV9q1birpzncYRupr1qnMoggMUHWq0IBYshFQrEO8PeVUZBw7/GfAeh3argdw2Qu748T Cyw= X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.91 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.917]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; 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)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEFALL_USER(0.00)[grahamperrin]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42a:from] X-Rspamd-Queue-Id: 4V36jx3GWzz4kq3 This is a multi-part message in MIME format. --------------GXZEcrSa0Jhf0C2FQUv6HGiB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Originally posted to Photograph: USB flash drive written from FreeBSD-15.0-CURRENT-amd64-20240314-220ee18f1964-268793-memstick.img.xz Broadcom Wi-Fi-related, maybe? Reproducible in safe mode. --------------GXZEcrSa0Jhf0C2FQUv6HGiB Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Originally posted to <https://discord.com/channels/727023752348434432/1221505362016862288>

Photograph: <https://media.discordapp.net/attachments/1221505362016862288/1221505364936364152/image.png?ex=6612d285&is=66005d85&hm=9b188930e96072deb379c61c52cca279c7cde78c0ba125199a62f336fe2083bd&=&format=webp&quality=lossless&width=915&height=686>

USB flash drive written from FreeBSD-15.0-CURRENT-amd64-20240314-220ee18f1964-268793-memstick.img.xz

Broadcom Wi-Fi-related, maybe? <https://bsd-hardware.info/?probe=89647876db#pci:14e4-4331-106b-00d6>

<https://cgit.freebsd.org/src/log/?qt=range&q=220ee18f1964>

Reproducible in safe mode.

--------------GXZEcrSa0Jhf0C2FQUv6HGiB-- From nobody Mon Mar 25 16:32:10 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4V3JPT4J0Qz5FGbb for ; Mon, 25 Mar 2024 16:32:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.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 4V3JPT1tVSz4WNN for ; Mon, 25 Mar 2024 16:32:29 +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=1711384345; bh=QancWgrpxcNDz0dsPIcAyBHL3gblxLAr7Ugq+kvkvo0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=nq3VF7oQuq0HPRhlEdZQe3+vnjFDM6Octcd7ZdoKdtPEqwwFoSrv3r9tJo7Qul6HAtaYT2XZ3yUWGrTrelMSTdXPEEuE524aYTqZVZfowx3qQAqkJDIS/igDNrp87TcxRqvaNIzl1u8krBbUybjtvNS6+AztmvEWzcmMorT5VepOperpAODpzuDHP1RlQSyyLKjWOsud+PuLzkiW+9Tgu8pkyqeMCuUH99QwENrePS9+yp3k47j9wGeidCtozfgHurimJ1BC1YUHZ+9wLNPup8ul9OdVFwwSsFyLdYvJ6NtmG7Teg+zHOGlghCLpg8TOoFI/wQZF+U0u7ve0hsvZzg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1711384345; bh=QfdodXZAWZPNir8dX/UUKFKMT7pux/9HHDSncwgTlBl=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=T3epzIu+LckX3tYewghe65lQbaoZtoJptW+Jz6fAruronogwox6tXps1KPlOwmxAiavTiQTItRKAOH3UgmHkYGO/x0UK6YYuk38/U8rvgBuBfF5P8zbxwlkSKHuO81Z5JPzmyJyyoF0iBtQsfZTN68Y7oBGD92lYjHrzK8Pg5dgRYhYC3nat05ZwuyYoOlmTN9J0JxGHZnMq8b1P0do20ew2tw1w00Gji1wTxirtf1eqqI13X4IEcpBgjC7xrD2Ico/DgQJ9Xz3wGP55UncIU3BTefmXMb6TIm20x1WW2PEKRWW2MERbOUbxtgE8ZbbQyNHvzrgtxlHlzVuTWaA6qw== X-YMail-OSG: olst9BEVM1nGPWOifO5grYG9pF8HZZh81awgjeHxIRzhV20FCTGY2KTIhqBgJaY S1czYNJHXsCFkUdicrl0ITO4f.ialThIMsU97tGY7WKkdGPL59rhvEeDqeeDf0NzUKKpYtuupD0K Bvkx8NbjYlQrpFkRd_wBnAY.fGNg.2.LvvpcGjvp8JqhwaJj9acq1kJYeX6gOKMaMqFwRQ7Cfgqj _7HzCJ0AXnk2tmPoG9G2yP5Hm6wgE9k5S4Aa3WhCS9arMKHIM2LNBFPRvzom1rySCx.aeiFmizD6 ovMJNzfv25.77zz1QcaWzZAXmK6bcds3VdtyaqqHvmo6cWFB8M9l9zaxq3sNMzl.m5j.DY6yGqcI 7TyquD4UXZZKu4.SQ.QNx5MUGT3LKwYn2TJbQPMbgSx0Oc5ZZubj7YgOEQQMjtm93VCF39H9NiPm CE0U9iG0C5r8SfAdIpEWbXNLTmvdpeOArtUoxIfgzb3XH4dTfflaZN_F5fHgjXQZVsN4Q4UKAfi8 08A18onuiiMQBQYaFZMyzq6K.584b3uakLTJgpolu1pE3lwDwO.A.1ohgYObCP3BCNyme0np3kYD mjnIE4SVlMXowqlGjEra.sCeyVGVs3NtMAZknmEr12AYeFgml6JpepwrfRebnSCkblbcRU5qOJj3 86eMB2kKcXA29yPx6n9i0iYICeiXKa2zDomVX.WqjRiVDY27FED.v3qukY9joVwZG1CVyTCcYO8o lv4dLDwFdlj9SNjyjOD6xWJTxsEf6pRrfYfAcg8n8jG3ZPpBdn_SKaMUJmR1DNoUt1z4UeUriAYf gNwIGAp94VqY_gzx6BwqmhacKtcleNITQ9J5.X2uEGQi8Pd6HNiiQmf0KZc_BP0PpYmEeR_Htugq YLbhpE.VLAcOvFLDLawDx.9SHNAwHzzUXJ1MpiGcYpmPazvTQ1jSxKGVF8ey5mCKord6ucFs9IXx Gsd_G9Pew7Dilxj8W7btYZd_qGGfQJIw5bg0Vd_YICSwEaOATEKNySMpKGdaIqCTFzQCaOf1PoYC _44HvhKyvpNzDuVXX.oyy.Fazad__9wbLKIsLJ3LwaWhfqP5LUC1R0L5sqsTKI8OJ1uMq57ZgHMH ovxfnT5IJ0l_EMjvQDKRf7PwVFU.V8JHy6FHCkzUSldJ5jrKdttAR3OquabXSaNLq1uKmsl9swcV WRbP6tGotoadJR6GDa1H9uH_ES0rlPzbm1DrllojSbwVchHbpNE4zPJilpFhRJtTADLW.Jq3ViuW VZdtnN5rhMYuPGcupVencIKN9d8hKSgEVsL3j0PkjmRAMxCyDhaLZCMogqVGdpoWQHJsKn0xhdEq MiS35Sr8sAjTvtJndYpq510H4kKRIP4oKHrtVt3HJU_JUNcwhkzbAZX37NWocichBFzRs4EVGEtB YCZnSwFSunnvaYlbOS3aUBDc4ocwPN6QflZyZvZRcHdxnF3y3MrWhCVbPaT4h2Rub8ugqrtbXaUq qhm1ImDgByP5O2ga.54H_7gVWQlsE8jUVrCRGlORcmGqrNPjTjH39mZaNclu4m5BDEhAITZPVAmP t4Mwp2Je0y3PC9G1pVvc8r2p3vHs__5A27_lVmiwNEHrrVKsJCWHk0JvLyNZDJ4ZjGda3Gnij4M. hajLRxqsZZSqwW7hbckm6VDRz4DZMuF_sitpJZY8kN.lpLLJm4AMmnEjC_KknL5WdWTCdLE1LYeW Nj9WP8xhdSworGR6bZ5JY2YQqvto_mSYeyEC71XVVQ5fJU6_ATYyII3U_I2f_zZ72bnw43o2_7aS jNXC01txbnTOyXokfKiDOdfYfaUyGRgwGmU9mofCoIqKL8k96vbDiHO6G8WeshMNQDI_OKpw1pLt rRHfouA3Osciqfv.vdbeFQPPJ0a1z.KvW_3tW6Zvsu4gAaQ2.dSns5EFaMrWDKIaj.lBIctoo04o 3e77e3ffKjo0GEuLPwV5cHjKtXPAfqS0gjzkz0cV95PTndC0gPCN6sWQ_aKFvvZlx5_3u_sWwpae 5XPR.Z9ni19h3KNVVzbd2mFxx0v3WhahAuXf5JsdY5542yw.1lXCOtLB30yPQUXw4CVbdu4KatBe Yz9JbDca4fprB7VZStq.8b_gdaWBNoPTmVdxrBDeAS92_4KRKkmBoR7DyUNFFbbgF3MEOVSP6AN7 YFa60iQ6BM3CtmZXSlfqBH_bY8XS3DPTJ4mWeqSk2aOKehZilIWUGVJu3IBqP4RHjh71yGEBTNkh y7Z6toFOviA7UJZbmihzC2KQgp_Zbfyc40wFfgHCB0KbOJorsxindN88iskH9RfPLA5iaMz1PiA- - X-Sonic-MF: X-Sonic-ID: c3805301-6132-47dc-ba07-2f7340502c23 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 25 Mar 2024 16:32:25 +0000 Received: by hermes--production-gq1-5c57879fdf-nxlqc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 00882307595d52349ab3a6a71109ab6c; Mon, 25 Mar 2024 16:32:20 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: after trivial update, 15.0 ARM64 system no longer boots From: Mark Millard In-Reply-To: Date: Mon, 25 Mar 2024 09:32:10 -0700 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <28FA0033-333C-4B0A-9BAA-4AB3E54FEF79@yahoo.com> References: To: Lexi Winter X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4V3JPT1tVSz4WNN On Mar 25, 2024, at 00:51, Lexi Winter wrote: > Lexi Winter: >> . . . > > . . . > > - even with the working keyboard, ctrl+alt+esc doesn't seem to work to > break into kdb when the problem occurs. i'm not sure if i'm doing > something wrong here or that key sequence doesn't work over USB, so i > wanted to try it via a serial console instead, which led to... > > . . . https://man.freebsd.org/cgi/man.cgi?ddb(4) reports: QUOTE Serial consoles can break to the debugger by sending a BREAK condition on the serial line. This requires a kernel built with options BREAK_TO_DEBUGGER is specified in the kernel. Most terminal emulation programs can send a break sequence with a special key sequence or menu selection. Sending the break can be difficult or even happen spuri- ously in some setups. An alternative method is to build a kernel with options ALT_BREAK_TO_DEBUGGER then the sequence of CR TILDE CTRL-B en- ters the debugger; CR TILDE CTRL-P causes a panic; and CR TILDE CTRL-R causes an immediate reboot. In all these sequences, CR represents Car- riage Return and is usually sent by pressing the Enter or Return key. TILDE is the ASCII tilde character (~). CTRL-x is Control x, sent by pressing the Control key, then x, then releasing both. END QUOTE Note the lack of mention of the ctrl+alt+esc . I expect that the: https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/ reference to "The default break-to-debugger sequence is Ctrl+Alt+ESC" may be x86/i386 specific (historical tier 1) or have some other specific type of context it applies to. I've historically used ALT_BREAK_TO_DEBUGGER and its CR TILDE CTRL-B on everything to get to the ddb> prompt via keyboards, including the serial console. (But, thinking about it, I've not used that in some time.) === Mark Millard marklmi at yahoo.com From nobody Tue Mar 26 17:43:33 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 4V3xx41ZYDz5FySk for ; Tue, 26 Mar 2024 17:43:36 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V3xx40bwvz51sQ; Tue, 26 Mar 2024 17:43:36 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711475016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3L5IICEz4izWpGjHJfNCTBF1dGzAAQp3yI0JKn5Ulkk=; b=lIllv4w1VHqFHp/MPpPJOemO9Fm5hFke3rrkH/FVir5HNyY1NwKS17lQ6eTPz8bpryfdXK AyRtT5nFFjQtwMEdrifZ5YRCGRQmIQM6t5qoyvaiInw1ew64rCWgGd9/8sD2juFuRnN7uk N4VbCTn/jpZ8Dr2g2vSAX6UO5KKpUi+FXrx6t9N4MRKCT3tV+1GS9hnXUk29YT1UwAAbfI UzLGVn7Z4ErnElnjpYqb0ochtI9DRa+yOo0m49zGtMXYzi41Yulupar68sgiBeUfju4+qj GoOX4+9jfWQGGpV/XroPIf8DGMBt6ND3XLHO1ZWY7sD5nnc6sKaSoFe7/YTUIg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711475016; a=rsa-sha256; cv=none; b=B2X3xir96nejQrJMbUnbq4yxORElrEf7mnXop0mSqits8d6ZL8twlnz12qFF0ieqhlOIGG uDK6eF3Pz7L56VqojxAugbTc5xeFcB6Tse4Vigzy4Ei+pHPuLDuOLEsuKpqoS3JbQZog9z Pjz8YIjnvqpdt1MSrX9gqMKpNvy+JgIy1EHCITQkEvpJwTq2ShZcVgcDnHucHA9VdNEmn2 G0mg3XRF+bex//sXAjHtQTvpkw+rQtT9lA+cDuUReJ1M2OColoelNrYxDN7BdC4xaRSUc2 TMFdP9Q2gb2MgNTphCUxKp12HMHN1Uu94Gne0t8U/r8l3WHGCJPEwalm1pOzKw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711475016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3L5IICEz4izWpGjHJfNCTBF1dGzAAQp3yI0JKn5Ulkk=; b=to5NS5saWUPMWSBoQaH3mR3XIby8HV9Hhfxc3HYVSA+eTkYiCCKocwzNZmywjenUNc4lZ3 zMam9rQUZKP9AlMYwKZfunF6HfTdRlRg38irBg3fJ3Yxu612iu+xz6iMMC8X/5nZAs5MVY MOwJiJ8gtoYx1w4vOdWIiuI2HZ0H4HLlGl7lxOE08sJkDf5A6zqw9qBzXYeBZK6s+pTX2F o5qmCNyqdOsypiDU+2uKqahiJKjq+hSNd8+0DoTw/70zpi8dp87xnl65I6g5H4gLR6DO6M W48dpYfrYVqqUtW8QuhX02dINvZavkHpEX+Aq/FS6rLMQV4gowCcxY+xp3iGTQ== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4V3xx34B59z1JHc; Tue, 26 Mar 2024 17:43:35 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 26 Mar 2024 10:43:33 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: March 2024 stabilization week Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi, On Mon, Mar 25, 2024 at 01:00:07AM -0700, Gleb Smirnoff wrote: T> This is an automated email to inform you that the March 2024 stabilization week T> started with FreeBSD/main at main-n268989-caccf6d3c008, which was tagged as T> main-stabweek-2024-Mar. A quick status update: * Netflix testing didn't discover any stability issues with main-n268989-caccf6d3c008, neither any significant performance degradations. * My personal desktop/server experience with the tag neither has any problems. Feel free to reply with your reports if you participated in the testing, too. A brief look at recent bugzilla submissions marks out one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277875 It is isolated to pf(4) and Kristof is already on it. It is unclear if 88f557a2a9c3 fixed it or not. I'm planning to end the advisory freeze on the main branch Wednesday morning at 8:00 UTC, unless somebody opposes that with a valid reason, e.g. a regression that I missed. Thanks everyone! -- Gleb Smirnoff From nobody Wed Mar 27 02:01:11 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 4V48zZ5vVNz5GDJY; Wed, 27 Mar 2024 02:01:30 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V48zY34gCz4b5k; Wed, 27 Mar 2024 02:01:29 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cicely.de header.s=default header.b=Ac3gyqEz; dmarc=none; spf=pass (mx1.freebsd.org: domain of ticso@cicely7.cicely.de designates 2a02:21e0:16e0:fe::101:1 as permitted sender) smtp.mailfrom=ticso@cicely7.cicely.de Received: from mail.cicely.de (mail.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:c]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id 42R21FRD007182 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Wed, 27 Mar 2024 03:01:17 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1711504878; bh=NBAII1RT9gf3isFyeuAXJev9p90ZiwtiuIXXNy0zyo8=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=Ac3gyqEzVFHYHrGmDD9JLA/C8III25bMYpqK/IxY2d8Dl267XLch1Duz0hOhqiYu3 ZonG2BytKhEoyLS3Rw2iginz7755WT0TmgnRz1xroc6fT9Mh10lVL3rm5OERdFMFQx Cxe7duFPL28wVaudK2FfVRc3ytk+iv+Di7A9MD3U= Received: from cicely7.cicely.de (c7-old.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:d]) by mail.cicely.de (8.16.1/8.16.1) with ESMTPS id 42R21DLA036343 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Mar 2024 03:01:13 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.17.1/8.17.1) with ESMTP id 42R21CSB093489; Wed, 27 Mar 2024 03:01:12 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.17.1/8.17.1/Submit) id 42R21BH2093488; Wed, 27 Mar 2024 03:01:11 +0100 (CET) (envelope-from ticso) Date: Wed, 27 Mar 2024 03:01:11 +0100 From: Bernd Walter To: freebsd-current@freebsd.org Cc: freebsd-hackers@freebsd.org, Bernd Walter Subject: Re: Only 1TB RAM out of 1.5TB on amd64 Message-ID: Reply-To: ticso@cicely.de References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 13.2-RELEASE-p3 amd64 X-Rspamd-Server: rspamd.fizon.de X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[freebsd-current@cicely.de,ticso@cicely7.cicely.de]; R_DKIM_ALLOW(-0.20)[cicely.de:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:44700, ipnet:2a02:21e0::/32, country:DE]; FREEFALL_USER(0.00)[ticso]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; DKIM_TRACE(0.00)[cicely.de:+]; DMARC_NA(0.00)[cicely.de]; MID_RHS_MATCH_FROMTLD(0.00)[]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[freebsd-current@cicely.de,ticso@cicely7.cicely.de]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[ticso@cicely.de]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4V48zY34gCz4b5k Same Problem with current: reeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC 2024 real memory = 1649265344512 (1572862 MB) avail memory = 1057118396416 (1008146 MB) On Fri, Mar 22, 2024 at 07:54:06PM +0100, Bernd Walter wrote: > .. > real memory = 1649265344512 (1572862 MB) > avail memory = 1057138888704 (1008166 MB) > .. > > I suspect address space issues, but don't know for sure. > Changing NUMA nodes per socket in the BIOS had an influence to make it > worse, but not better. > > > Copyright (c) 1992-2021 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.3-RELEASE releng/13.3-n257428-80d2b634ddf0 GENERIC amd64 > FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367) > VT(efifb): resolution 1024x768 > CPU: AMD EPYC 7352 24-Core Processor (2300.07-MHz K8-class CPU) > Origin="AuthenticAMD" Id=0x830f10 Family=0x17 Model=0x31 Stepping=0 > Features=0x178bfbff > Features2=0x7ed8320b > AMD Features=0x2e500800 > AMD Features2=0x75c237ff > Structured Extended Features=0x219c91a9 > Structured Extended Features2=0x400004 > XSAVE Features=0xf > AMD Extended Feature Extensions ID EBX=0x18cf757 > SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 > TSC: P-state invariant, performance statistics > real memory = 1649265344512 (1572862 MB) > avail memory = 1057138888704 (1008166 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 96 CPUs > FreeBSD/SMP: 2 package(s) x 8 cache groups x 3 core(s) x 2 hardware threads > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > random: unblocking device. > ioapic0 irqs 0-23 > ioapic1 irqs 24-55 > ioapic2 irqs 56-87 > ioapic3 irqs 88-119 > ioapic4 irqs 120-151 > ioapic5 irqs 152-183 > ioapic6 irqs 184-215 > ioapic7 irqs 216-247 > ioapic8 irqs 248-279 > Launching APs: 32 30 34 13 14 16 23 21 19 24 28 9 86 10 87 7 26 37 39 41 45 46 43 66 71 69 54 57 59 80 82 78 49 53 51 60 65 62 84 88 91 95 74 73 76 92 33 40 11 2 27 22 20 5 44 18 15 36 6 8 25 89 79 85 93 56 48 70 31 81 12 50 38 77 55 63 75 58 1 90 29 94 52 72 67 83 35 42 61 64 68 47 4 17 3 > random: entropy device external interface > kbd1 at kbdmux0 > .. > > kern.maxphys: 1048576 > hw.physmem: 1099322220544 > hw.usermem: 1091323355136 > hw.realmem: 1649265344512 > vm.phys_locality: > 0: 10 32 > 1: 32 10 > > vm.phys_segs: > SEGMENT 0: > > start: 0x10000 > end: 0xa0000 > domain: 0 > free list: 0xffffffff81ec7ea0 > > SEGMENT 1: > > start: 0x100000 > end: 0x1000000 > domain: 0 > free list: 0xffffffff81ec7ea0 > > SEGMENT 2: > > start: 0x1000000 > end: 0x74000000 > domain: 0 > free list: 0xffffffff81ec7c30 > > SEGMENT 3: > > start: 0x74043000 > end: 0x75db0000 > domain: 0 > free list: 0xffffffff81ec7c30 > > SEGMENT 4: > > start: 0x76000000 > end: 0x963b8000 > domain: 0 > free list: 0xffffffff81ec7c30 > > SEGMENT 5: > > start: 0x963c2000 > end: 0x963f9000 > domain: 0 > free list: 0xffffffff81ec7c30 > > SEGMENT 6: > > start: 0x96500000 > end: 0xa57f7000 > domain: 0 > free list: 0xffffffff81ec7c30 > > SEGMENT 7: > > start: 0xa8e96000 > end: 0xac000000 > domain: 0 > free list: 0xffffffff81ec7c30 > > SEGMENT 8: > > start: 0x10000e000 > end: 0x7d07800000 > domain: 0 > free list: 0xffffffff81ec79c0 > > SEGMENT 9: > > start: 0x10000019000 > end: 0x1797de00000 > domain: 1 > free list: 0xffffffff81ec8110 > > SEGMENT 10: > > start: 0x17ffdc00000 > end: 0x17ffdde7000 > domain: 1 > free list: 0xffffffff81ec8110 > > > > -- > B.Walter https://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > -- B.Walter https://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From nobody Wed Mar 27 09:37:48 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4V4M6B1khLz5F5jm for ; Wed, 27 Mar 2024 09:37:54 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4M692x9Zz4R5k for ; Wed, 27 Mar 2024 09:37:53 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de Received: from [212.222.85.114] (helo=pureos) by ms-10.1blu.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1rpPjC-001dlD-Kt; Wed, 27 Mar 2024 10:37:50 +0100 Date: Wed, 27 Mar 2024 10:37:48 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Cc: Michael Gmelin Subject: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org, Michael Gmelin List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 14.0-CURRENT 1400094 (amd64) X-message-flag: Mails in HTML will not be read! Send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 212.222.85.114 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.95)[0.949]; NEURAL_HAM_SHORT(-0.54)[-0.543]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[unixarea.de]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[guru@unixarea.de]; HAS_XOIP(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4V4M692x9Zz4R5k Hello, I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to boot FreeBSD with boot verbose messages from an USB key and I'm able to login. The /var/log/messages are here http://www.unixarea.de/ASUS-VivoBook-Pro-14-messages.txt I can identify the harddisk as nda0 (correct), but don't see any mouse and WLAN card. I will also boot an Ubuntu 22.04.4 from USB, maybe this gives more hints about hardware details. Thanks for any comments. I have 30 days to return the laptop to the store. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Wed Mar 27 09:56:45 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 4V4MXV5hxYz5F6tR for ; Wed, 27 Mar 2024 09:57:14 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4MXV3QFyz4TSb for ; Wed, 27 Mar 2024 09:57:14 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-4782308e218so816884137.0 for ; Wed, 27 Mar 2024 02:57:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711533433; x=1712138233; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sarfiRxLt0lMME/z4tLbdqkFlLvj9TrxB2woYYYTfWc=; b=OTbVfxfkL1R5ygRHbw4Vx3xULU//aYPOFTzq3+tz9oM6ujFLfVMixpbmptGTKxIkBg xAme2Wv42dJN3e6aGqmwjuNYFgUkF8T4M2GuCWbKgEFbEGos0GCH+uzCQ86jrmXom/Jh fFUOrz989sVb68gmJbwd27pTcAOg7b/bYOuyek+q29RvJn7++4Wgqm06q8GGhfYWic9t 4stbO2T4dukymfhgVCv4uK8EEQOPcMoe2GWptL+S9Ld5u2CigGVGAtF0mvJW0RdxZGDA JJP0fq2Q1RuDD+iwCARTDpfLZ3RL7ilqWklOI2tmX3knBrTJZ2hRY31SD8K6lwJO+ebB DLbQ== X-Gm-Message-State: AOJu0Yx8uDdsKFOgEVwJoBaJ4bMK1j8mRMhmzYkNL5rNpJ0ecyYUfqtH zdILWghupDj94mbgX+7fRapO5ipovz3Vbmn4qH/SBW27Znd0omOgSI+2WQh+n5EMCA== X-Google-Smtp-Source: AGHT+IFnhy6L1JjA/8+g2zHk1GyibYixP6ozfQ9RROt1iKvHlpJ+JzX+v6qg3Bw6zWoK07DQp2rOvQ== X-Received: by 2002:a67:e412:0:b0:478:40f8:6bb6 with SMTP id d18-20020a67e412000000b0047840f86bb6mr5605vsf.3.1711533433231; Wed, 27 Mar 2024 02:57:13 -0700 (PDT) Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com. [209.85.217.48]) by smtp.gmail.com with ESMTPSA id l17-20020ab07191000000b007e0ffab87a0sm985596uao.9.2024.03.27.02.57.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Mar 2024 02:57:13 -0700 (PDT) Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-475ffc62cbaso1864689137.1 for ; Wed, 27 Mar 2024 02:57:13 -0700 (PDT) X-Received: by 2002:a67:fd8c:0:b0:476:f6cb:5034 with SMTP id k12-20020a67fd8c000000b00476f6cb5034mr326382vsq.14.1711533432865; Wed, 27 Mar 2024 02:57:12 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Gleb Popov Date: Wed, 27 Mar 2024 12:56:45 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 To: Matthias Apitz Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4V4MXV3QFyz4TSb On Wed, Mar 27, 2024 at 12:38=E2=80=AFPM Matthias Apitz = wrote: > > > Hello, > > I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to > boot FreeBSD with boot verbose messages from an USB key and I'm able to > login. The /var/log/messages are here > http://www.unixarea.de/ASUS-VivoBook-Pro-14-messages.txt `pciconf -lv` would be useful too. From nobody Wed Mar 27 12:00:07 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4V4QGY0rlrz5FL6F for ; Wed, 27 Mar 2024 12:00:21 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4QGX2jXHz4jXx; Wed, 27 Mar 2024 12:00:20 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=fzMMdp3K; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=mjguzik@gmail.com Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a470d7f77eeso841943666b.3; Wed, 27 Mar 2024 05:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711540819; x=1712145619; darn=freebsd.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=LVS1oPl0ezTxxy2L/VucHpCeSsxqFbOfjIjQcPegtds=; b=fzMMdp3K/PN3RXo4bzqYSnFzzxC3YzeeFvDwAeWM2+3Axr5AuBTaWL8PrLpfLEdvec DmfQHaAYm5giEfCjZ+yXto4gRfAKvLFp7Zy2VJo2O7dhzV+xKNyeM8CrGd7uNQh8XyQx ocVwtwq7XbxapA83YDvKCcv03NDub3sZcF53meUJhgIfnOD7VgWJyCP8SWSdxJM8RkJK da57aGOvFotwbEjdL4MHAVaBQ+6dUsXrKGaa9z4xdMztkUDduM1IcQesKDazDK8gDpCa AlsnCfs3oDyHyV84T9RJeEjR5nNyz5OhWsrJoagqNGte1uPrIdCHF5C7StqYBrDB/vOk J3AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711540819; x=1712145619; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=LVS1oPl0ezTxxy2L/VucHpCeSsxqFbOfjIjQcPegtds=; b=EveshMlTV0uaQcQ9Gcrawuut/ekyQPnsIE0NeQAQRpbM4Zq1uhS+go8Yk1gErUDypd ibLOp6ZzNEXAeYwE8gBl/mceAhPkkIQfYlJU+waj6W9UmLAhvch+YNs8ixsCAkFrt4t8 Mho5bT283gsP80xHC7ycBBnypRMDQ4uubR6xWQwZW7K6t36QUEMbBDb1aZ9HuO87kHSF JCaeEDZOc03CqDzRjJkPLactKqw3eR0XgxO2iHm52hiy2Wqam/yp2OesfjF8LXdcyNMU jmkQUoijL6sZujSZ8MVIxSajwO28dp+/sK4VbYBsV5KsaoW76lo9u1UWBqFL3XpFW5SD AQ+g== X-Gm-Message-State: AOJu0Yyl7HM0IdBh7WCHIJ47xBWCQ9aF3cjtykm39WTGCHV04du7yWv3 WmFkjjx3uf6U/HdytGFcOwSW3eF1UOOtQm5rgasBbkiz1gV9wM7RfWiRINIRO5UAgc55ykvoSLw dEjZdldozcHdRRKC3/hfk+2AZaHd4WOUm/Wk= X-Google-Smtp-Source: AGHT+IHR0muEiI+vzQSoLkZ+lFmhSbrffxTNX3taJ0pk4cF2zemufP4vFVgnjFP4pbQ5fWxQT4vHbUinTg4OE4vK7no= X-Received: by 2002:a17:906:af06:b0:a47:2ec5:57dd with SMTP id lx6-20020a170906af0600b00a472ec557ddmr810696ejb.72.1711540818899; Wed, 27 Mar 2024 05:00:18 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Mateusz Guzik Date: Wed, 27 Mar 2024 13:00:07 +0100 Message-ID: Subject: truss -f timeout 2 sleep 10 causes breakage To: Konstantin Belousov Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.92 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.915]; 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:c]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+] X-Rspamd-Queue-Id: 4V4QGX2jXHz4jXx Top of main, but I reproduced it on stable/14-e64d827d3 as well. Mere "timeout 2 sleep 10" correctly times out. Running "truss -f timeout 2 sleep 10" prevents timeout from killing sleep and the entire thing refuses to exit, truss has to be killed off with SIGKILL. Here is the best part: after doing the above, going back to mere "timeout 2 sleep 10" (without truss!) no longer works -- timeout gets stuck in the kernel: mi_switch sleepq_catch_signals sleepq_wait_sig _sx_xlock_hard stop_all_proc_block kern_procctl sys_procctl amd64_syscall fast_syscall_common It does react to -9 though. -- Mateusz Guzik From nobody Wed Mar 27 12:16:13 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 4V4Qcx1Jw5z5FMST for ; Wed, 27 Mar 2024 12:16:17 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4Qcx0l6Hz4mBs; Wed, 27 Mar 2024 12:16:17 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711541777; 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=52102yz2Z+vdPntbGxEjuVhdEkBwJakDYvYSEICwSO4=; b=xUls4sdd2i+ucHR2Ax3p/186vu4+TySBiBXuO0Toc0HLr0RY4MTeUEBgn+bX45ch9U4SoE YsEZF9aVsvSfia9yGfvh4gjhFTiqaLOl18LCCGsKChVFXvI3mFaiIgPyVzpT2x7i2Rsgd4 /dACtIL6jIcPP5PGK0VmH4kUcPabVHaNAlOMYblfmhZ9YOUsThhrOT3zU9VWd1LAKqXxs8 YiKgrRSJdLj+tD9E1iXkv6Bxh7buJjaoJ+5Jv1j2z6qJr5GvgfoOdxtijOJJR9esRWtQ4A vIVoPfd/BrqHPwimggBL9bNKS3C4RVoTHvcv4WXEtD1diKTHQoAd0g1F/A6t8g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711541777; a=rsa-sha256; cv=none; b=Zh+K14UAiAgkL4mIGCLpkG2ESgEABbsBdNKB7fIPFEyshU87LvrDg3Ir6QuXP8HNRzATYJ ZxP0kMwgNPyXDioL+kGB0RPTAXg5eXGZ1rO1g6dN7beCLqbkB0YZcrzR8kE2xojx93IYxI xjovJ4pDw5zmC0na3kTU4kL/bl2WKuPR7FiGXKbr6C3EjqcRhgs0ZNH4RjDYHGE05l2TgR ktibGQmdsp1wc0ggmjYMbCil2I1T5fQxvcensZgyB/20gExvzylpzGtnZjGRxRVxbPxL8O CIu0rnXYzEG7oGtcvkF/kQofrrksNtkUFPoN6hHM3ZTziUrMLZV+PNk9UEl0Hg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711541777; 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=52102yz2Z+vdPntbGxEjuVhdEkBwJakDYvYSEICwSO4=; b=SD6bsx9BUNcQh/nNibziqsTM/JfjX1iW1sCbWMI2CDKcHHTn2RbUy8YKGiJsXbeF4hs65i kv2DRxJghjXgnvWdQM/49Dc1u5HvqbfcYpyH/iiGY40QN60y3BCElDDtHzi9BpJcbHcdCv rhyZsKzwLItAqcyRj2LCTTThxxs0F0nYcGfgyCgFP2JfzRFri9y7mh9l+0UnCdXKi8XrA6 H3uFWsg8FVlR5J9ceH23dMUtuTcfUTv/56Xpn1akxBs1Csvp85KMelNyiLYjbqTNghbAiz zBkYXvcewI5bchGUNq5hVlXT1IpmYjiEFyFTCNKQsJFBXG99WfPrVWCaGPeCew== Received: from ltc.des.dev (2a02-8428-0993-f001-922e-16ff-fef1-acef.rev.sfr.net [IPv6:2a02:8428:993:f001:922e:16ff:fef1:acef]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4V4Qcw6jgXzP0b; Wed, 27 Mar 2024 12:16:16 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id E06BE684; Wed, 27 Mar 2024 13:16:13 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mateusz Guzik Cc: Konstantin Belousov , FreeBSD Current Subject: Re: truss -f timeout 2 sleep 10 causes breakage In-Reply-To: (Mateusz Guzik's message of "Wed, 27 Mar 2024 13:00:07 +0100") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 27 Mar 2024 13:16:13 +0100 Message-ID: <86wmpnc1ki.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mateusz Guzik writes: > Top of main, but I reproduced it on stable/14-e64d827d3 as well. Confirmed on 14.0-RELEASE-p5. > Mere "timeout 2 sleep 10" correctly times out. > > Running "truss -f timeout 2 sleep 10" prevents timeout from killing > sleep This is sort of expected as truss(1) uses ptrace(2) which breaks the parent-child relationship, so you should never use `truss -f` with a command that expects to control its children. > and the entire thing refuses to exit, truss has to be killed off > with SIGKILL. This, however, is not expected. > Here is the best part: after doing the above, going back to mere > "timeout 2 sleep 10" (without truss!) no longer works Neither is this. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Wed Mar 27 12:34:19 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 4V4R1z25GWz5FNsF for ; Wed, 27 Mar 2024 12:34:31 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4R1y2yMzz4pR4 for ; Wed, 27 Mar 2024 12:34:30 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 42RCYJo4037471; Wed, 27 Mar 2024 14:34:22 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 42RCYJo4037471 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 42RCYJ5i037470; Wed, 27 Mar 2024 14:34:19 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Wed, 27 Mar 2024 14:34:19 +0200 From: Konstantin Belousov To: Mateusz Guzik Cc: FreeBSD Current Subject: Re: truss -f timeout 2 sleep 10 causes breakage Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4V4R1y2yMzz4pR4 On Wed, Mar 27, 2024 at 01:00:07PM +0100, Mateusz Guzik wrote: > Top of main, but I reproduced it on stable/14-e64d827d3 as well. > > Mere "timeout 2 sleep 10" correctly times out. > > Running "truss -f timeout 2 sleep 10" prevents timeout from killing > sleep and the entire thing refuses to exit, truss has to be killed off > with SIGKILL. The issue is because debugger can stop the debuggee, which makes the single threading never succeed. Supposed fix is in https://reviews.freebsd.org/D44523 the cost is that in principle, the debuggee now can try to break out of the reaper kill hammer, with the help of debugger. But this setup is arguably too convoluted: you either control the process with reaper, or with debugger. > > Here is the best part: after doing the above, going back to mere > "timeout 2 sleep 10" (without truss!) no longer works -- timeout gets > stuck in the kernel: mi_switch sleepq_catch_signals sleepq_wait_sig > _sx_xlock_hard stop_all_proc_block kern_procctl sys_procctl > amd64_syscall fast_syscall_common This is because the threaded workqueue thread is stuck waiting for single-threading of the victim. > > It does react to -9 though. Not the workqueue, which is the problem. From nobody Wed Mar 27 14:51:33 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 4V4V4914l0z5FcS3 for ; Wed, 27 Mar 2024 14:51:37 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4V482BpMz4456 for ; Wed, 27 Mar 2024 14:51:36 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de Received: from [62.216.207.219] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1rpUco-007y4F-3U; Wed, 27 Mar 2024 15:51:34 +0100 Received: from localhost.my.domain (c720-1400094 [127.0.0.1]) by localhost.unixarea.de (8.17.1/8.14.9) with ESMTP id 42REpXZa002043; Wed, 27 Mar 2024 15:51:33 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.17.1/8.14.9/Submit) id 42REpXel002042; Wed, 27 Mar 2024 15:51:33 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Wed, 27 Mar 2024 15:51:33 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org, Michael Gmelin Subject: Re: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org, Michael Gmelin References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 14.0-CURRENT r1400094 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 62.216.207.219 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.76 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.962]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[unixarea.de]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; MISSING_XM_UA(0.00)[]; HAS_XAW(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[guru@unixarea.de]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_XOIP(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4V4V482BpMz4456 El día miércoles, marzo 27, 2024 a las 10:37:48a. m. +0100, Matthias Apitz escribió: > > Hello, > > I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to > boot FreeBSD with boot verbose messages from an USB key and I'm able to > login. The /var/log/messages are here > http://www.unixarea.de/ASUS-VivoBook-Pro-14-messages.txt A 'gpart list nda0' is here http://www.unixarea.de/nda0.txt Actual the (Windows) partitions are: # egrep 'Name:|Mediasize:' nda0.txt 1. Name: nda0p1 Mediasize: 272629760 (260M) 2. Name: nda0p2 Mediasize: 16777216 (16M) 3. Name: nda0p3 Mediasize: 510507949568 (475G) 4. Name: nda0p4 Mediasize: 1101004800 (1.0G) 5. Name: nda0p5 Mediasize: 209715200 (200M) 1. Name: nda0 Mediasize: 512110190592 (477G) A 'pciconf -lv' is here: http://www.unixarea.de/pciconf.txt The WLAN card seems to be: none2@pci0:1:0:0: class=0x028000 rev=0x00 hdr=0x00 vendor=0x14c3 device=0x7961 subvendor=0x1a3b subdevice=0x4680 vendor = 'MEDIATEK Corp.' device = 'MT7921 802.11ax PCI Express Wireless Network Adapter' class = network Perhaps not supported until today: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264300 An attached USB mouse is detected and works. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Wed Mar 27 15:55: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 4V4WV32YjPz5FjdD; Wed, 27 Mar 2024 15:55:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4WV26HSMz4Cvl; Wed, 27 Mar 2024 15:55:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 42RFtK40088677; Wed, 27 Mar 2024 17:55:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 42RFtK40088677 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 42RFtK9H088674; Wed, 27 Mar 2024 17:55:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Mar 2024 17:55:20 +0200 From: Konstantin Belousov To: ticso@cicely.de Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, Bernd Walter Subject: Re: Only 1TB RAM out of 1.5TB on amd64 Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4V4WV26HSMz4Cvl On Wed, Mar 27, 2024 at 03:01:11AM +0100, Bernd Walter wrote: > Same Problem with current: > reeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC 2024 > > real memory = 1649265344512 (1572862 MB) > avail memory = 1057118396416 (1008146 MB) Real memory is really the max physical address of the valid byte. If you have holes in the phys map, real memory should reflect these holes. Avail memory is the total memory as reported by EFI map. Verify all that by looking at sysctl machdep.efi_map output. > > On Fri, Mar 22, 2024 at 07:54:06PM +0100, Bernd Walter wrote: > > .. > > real memory = 1649265344512 (1572862 MB) > > avail memory = 1057138888704 (1008166 MB) > > .. > > > > I suspect address space issues, but don't know for sure. > > Changing NUMA nodes per socket in the BIOS had an influence to make it > > worse, but not better. > > > > > > Copyright (c) 1992-2021 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 13.3-RELEASE releng/13.3-n257428-80d2b634ddf0 GENERIC amd64 > > FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367) > > VT(efifb): resolution 1024x768 > > CPU: AMD EPYC 7352 24-Core Processor (2300.07-MHz K8-class CPU) > > Origin="AuthenticAMD" Id=0x830f10 Family=0x17 Model=0x31 Stepping=0 > > Features=0x178bfbff > > Features2=0x7ed8320b > > AMD Features=0x2e500800 > > AMD Features2=0x75c237ff > > Structured Extended Features=0x219c91a9 > > Structured Extended Features2=0x400004 > > XSAVE Features=0xf > > AMD Extended Feature Extensions ID EBX=0x18cf757 > > SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 > > TSC: P-state invariant, performance statistics > > real memory = 1649265344512 (1572862 MB) > > avail memory = 1057138888704 (1008166 MB) > > Event timer "LAPIC" quality 600 > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 96 CPUs > > FreeBSD/SMP: 2 package(s) x 8 cache groups x 3 core(s) x 2 hardware threads > > random: registering fast source Intel Secure Key RNG > > random: fast provider: "Intel Secure Key RNG" > > random: unblocking device. > > ioapic0 irqs 0-23 > > ioapic1 irqs 24-55 > > ioapic2 irqs 56-87 > > ioapic3 irqs 88-119 > > ioapic4 irqs 120-151 > > ioapic5 irqs 152-183 > > ioapic6 irqs 184-215 > > ioapic7 irqs 216-247 > > ioapic8 irqs 248-279 > > Launching APs: 32 30 34 13 14 16 23 21 19 24 28 9 86 10 87 7 26 37 39 41 45 46 43 66 71 69 54 57 59 80 82 78 49 53 51 60 65 62 84 88 91 95 74 73 76 92 33 40 11 2 27 22 20 5 44 18 15 36 6 8 25 89 79 85 93 56 48 70 31 81 12 50 38 77 55 63 75 58 1 90 29 94 52 72 67 83 35 42 61 64 68 47 4 17 3 > > random: entropy device external interface > > kbd1 at kbdmux0 > > .. > > > > kern.maxphys: 1048576 > > hw.physmem: 1099322220544 > > hw.usermem: 1091323355136 > > hw.realmem: 1649265344512 > > vm.phys_locality: > > 0: 10 32 > > 1: 32 10 > > > > vm.phys_segs: > > SEGMENT 0: > > > > start: 0x10000 > > end: 0xa0000 > > domain: 0 > > free list: 0xffffffff81ec7ea0 > > > > SEGMENT 1: > > > > start: 0x100000 > > end: 0x1000000 > > domain: 0 > > free list: 0xffffffff81ec7ea0 > > > > SEGMENT 2: > > > > start: 0x1000000 > > end: 0x74000000 > > domain: 0 > > free list: 0xffffffff81ec7c30 > > > > SEGMENT 3: > > > > start: 0x74043000 > > end: 0x75db0000 > > domain: 0 > > free list: 0xffffffff81ec7c30 > > > > SEGMENT 4: > > > > start: 0x76000000 > > end: 0x963b8000 > > domain: 0 > > free list: 0xffffffff81ec7c30 > > > > SEGMENT 5: > > > > start: 0x963c2000 > > end: 0x963f9000 > > domain: 0 > > free list: 0xffffffff81ec7c30 > > > > SEGMENT 6: > > > > start: 0x96500000 > > end: 0xa57f7000 > > domain: 0 > > free list: 0xffffffff81ec7c30 > > > > SEGMENT 7: > > > > start: 0xa8e96000 > > end: 0xac000000 > > domain: 0 > > free list: 0xffffffff81ec7c30 > > > > SEGMENT 8: > > > > start: 0x10000e000 > > end: 0x7d07800000 > > domain: 0 > > free list: 0xffffffff81ec79c0 > > > > SEGMENT 9: > > > > start: 0x10000019000 > > end: 0x1797de00000 > > domain: 1 > > free list: 0xffffffff81ec8110 > > > > SEGMENT 10: > > > > start: 0x17ffdc00000 > > end: 0x17ffdde7000 > > domain: 1 > > free list: 0xffffffff81ec8110 > > > > > > > > -- > > B.Walter https://www.bwct.de > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > > > > -- > B.Walter https://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From nobody Wed Mar 27 16:29: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 4V4XFb4X43z5FmdM; Wed, 27 Mar 2024 16:29:55 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4XFZ6zxfz4JQq; Wed, 27 Mar 2024 16:29:54 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Authentication-Results: mx1.freebsd.org; none Received: from mail.cicely.de (mail.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:c]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id 42RGTlPU029767 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Wed, 27 Mar 2024 17:29:50 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1711556990; bh=fByhYszKjckUNt9Bvb3w4qY6RMUwUbrFGSljt9RardQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=J9wf+S1XY6BhfFvkpCN/RRhXlOJ0HJ+Zc5xhI5kxvJR3RwvDtD3iWMi8XjukOLEl4 oPbscVLVUD4HrYdF4NYYjhTYEBsto0Tsvv5idpTtMy2yNssHH3u9GhejH30f+DUNml wHEcJxM1+9H0pcTaRqA49ihOjXRSdTQ8/KoxjcVw= Received: from cicely7.cicely.de (c7-old.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:d]) by mail.cicely.de (8.16.1/8.16.1) with ESMTPS id 42RGTlcB057531 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Mar 2024 17:29:47 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.17.1/8.17.1) with ESMTP id 42RGTl9d000426; Wed, 27 Mar 2024 17:29:47 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.17.1/8.17.1/Submit) id 42RGTlQd000425; Wed, 27 Mar 2024 17:29:47 +0100 (CET) (envelope-from ticso) Date: Wed, 27 Mar 2024 17:29:47 +0100 From: Bernd Walter To: Konstantin Belousov Cc: ticso@cicely.de, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, Bernd Walter Subject: Re: Only 1TB RAM out of 1.5TB on amd64 Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 13.2-RELEASE-p3 amd64 X-Rspamd-Server: rspamd.fizon.de X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:44700, ipnet:2a02:21e0::/32, country:DE] X-Rspamd-Queue-Id: 4V4XFZ6zxfz4JQq On Wed, Mar 27, 2024 at 05:55:20PM +0200, Konstantin Belousov wrote: > On Wed, Mar 27, 2024 at 03:01:11AM +0100, Bernd Walter wrote: > > Same Problem with current: > > reeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC 2024 > > > > real memory = 1649265344512 (1572862 MB) > > avail memory = 1057118396416 (1008146 MB) > Real memory is really the max physical address of the valid byte. > If you have holes in the phys map, real memory should reflect these > holes. Avail memory is the total memory as reported by EFI map. Damn - thank you very much. That was the answer. I was under the impression that the machine has 1.5T installed, but in fact it has only 1T installed. I was expecting holes because of NUMA, but my assumption was more that the holes would led to memory being outside of the direct map space. > > Verify all that by looking at sysctl machdep.efi_map output. > > > > On Fri, Mar 22, 2024 at 07:54:06PM +0100, Bernd Walter wrote: > > > .. > > > real memory = 1649265344512 (1572862 MB) > > > avail memory = 1057138888704 (1008166 MB) > > > .. > > > > > > I suspect address space issues, but don't know for sure. > > > Changing NUMA nodes per socket in the BIOS had an influence to make it > > > worse, but not better. > > > > > > > > > Copyright (c) 1992-2021 The FreeBSD Project. > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > The Regents of the University of California. All rights reserved. > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > FreeBSD 13.3-RELEASE releng/13.3-n257428-80d2b634ddf0 GENERIC amd64 > > > FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367) > > > VT(efifb): resolution 1024x768 > > > CPU: AMD EPYC 7352 24-Core Processor (2300.07-MHz K8-class CPU) > > > Origin="AuthenticAMD" Id=0x830f10 Family=0x17 Model=0x31 Stepping=0 > > > Features=0x178bfbff > > > Features2=0x7ed8320b > > > AMD Features=0x2e500800 > > > AMD Features2=0x75c237ff > > > Structured Extended Features=0x219c91a9 > > > Structured Extended Features2=0x400004 > > > XSAVE Features=0xf > > > AMD Extended Feature Extensions ID EBX=0x18cf757 > > > SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 > > > TSC: P-state invariant, performance statistics > > > real memory = 1649265344512 (1572862 MB) > > > avail memory = 1057138888704 (1008166 MB) > > > Event timer "LAPIC" quality 600 > > > ACPI APIC Table: > > > FreeBSD/SMP: Multiprocessor System Detected: 96 CPUs > > > FreeBSD/SMP: 2 package(s) x 8 cache groups x 3 core(s) x 2 hardware threads > > > random: registering fast source Intel Secure Key RNG > > > random: fast provider: "Intel Secure Key RNG" > > > random: unblocking device. > > > ioapic0 irqs 0-23 > > > ioapic1 irqs 24-55 > > > ioapic2 irqs 56-87 > > > ioapic3 irqs 88-119 > > > ioapic4 irqs 120-151 > > > ioapic5 irqs 152-183 > > > ioapic6 irqs 184-215 > > > ioapic7 irqs 216-247 > > > ioapic8 irqs 248-279 > > > Launching APs: 32 30 34 13 14 16 23 21 19 24 28 9 86 10 87 7 26 37 39 41 45 46 43 66 71 69 54 57 59 80 82 78 49 53 51 60 65 62 84 88 91 95 74 73 76 92 33 40 11 2 27 22 20 5 44 18 15 36 6 8 25 89 79 85 93 56 48 70 31 81 12 50 38 77 55 63 75 58 1 90 29 94 52 72 67 83 35 42 61 64 68 47 4 17 3 > > > random: entropy device external interface > > > kbd1 at kbdmux0 > > > .. > > > > > > kern.maxphys: 1048576 > > > hw.physmem: 1099322220544 > > > hw.usermem: 1091323355136 > > > hw.realmem: 1649265344512 > > > vm.phys_locality: > > > 0: 10 32 > > > 1: 32 10 > > > > > > vm.phys_segs: > > > SEGMENT 0: > > > > > > start: 0x10000 > > > end: 0xa0000 > > > domain: 0 > > > free list: 0xffffffff81ec7ea0 > > > > > > SEGMENT 1: > > > > > > start: 0x100000 > > > end: 0x1000000 > > > domain: 0 > > > free list: 0xffffffff81ec7ea0 > > > > > > SEGMENT 2: > > > > > > start: 0x1000000 > > > end: 0x74000000 > > > domain: 0 > > > free list: 0xffffffff81ec7c30 > > > > > > SEGMENT 3: > > > > > > start: 0x74043000 > > > end: 0x75db0000 > > > domain: 0 > > > free list: 0xffffffff81ec7c30 > > > > > > SEGMENT 4: > > > > > > start: 0x76000000 > > > end: 0x963b8000 > > > domain: 0 > > > free list: 0xffffffff81ec7c30 > > > > > > SEGMENT 5: > > > > > > start: 0x963c2000 > > > end: 0x963f9000 > > > domain: 0 > > > free list: 0xffffffff81ec7c30 > > > > > > SEGMENT 6: > > > > > > start: 0x96500000 > > > end: 0xa57f7000 > > > domain: 0 > > > free list: 0xffffffff81ec7c30 > > > > > > SEGMENT 7: > > > > > > start: 0xa8e96000 > > > end: 0xac000000 > > > domain: 0 > > > free list: 0xffffffff81ec7c30 > > > > > > SEGMENT 8: > > > > > > start: 0x10000e000 > > > end: 0x7d07800000 > > > domain: 0 > > > free list: 0xffffffff81ec79c0 > > > > > > SEGMENT 9: > > > > > > start: 0x10000019000 > > > end: 0x1797de00000 > > > domain: 1 > > > free list: 0xffffffff81ec8110 > > > > > > SEGMENT 10: > > > > > > start: 0x17ffdc00000 > > > end: 0x17ffdde7000 > > > domain: 1 > > > free list: 0xffffffff81ec8110 > > > > > > > > > > > > -- > > > B.Walter https://www.bwct.de > > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > > > > > > > -- > > B.Walter https://www.bwct.de > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. -- B.Walter https://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From nobody Thu Mar 28 09:18:15 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 4V4yd86YpSz5FMSb for ; Thu, 28 Mar 2024 09:18:20 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4yd75mddz44bL for ; Thu, 28 Mar 2024 09:18:19 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de Received: from [212.222.85.114] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1rplto-006nv2-VN; Thu, 28 Mar 2024 10:18:16 +0100 Received: from localhost.my.domain (c720-1400094 [127.0.0.1]) by localhost.unixarea.de (8.17.1/8.14.9) with ESMTP id 42S9IGTj003732; Thu, 28 Mar 2024 10:18:16 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.17.1/8.14.9/Submit) id 42S9IFb0003731; Thu, 28 Mar 2024 10:18:15 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Thu, 28 Mar 2024 10:18:15 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org, Michael Gmelin Subject: Re: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org, Michael Gmelin References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bqtZ2oA6fjYMiWZP" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 14.0-CURRENT r1400094 (amd64) X-message-flag: Mails in HTML will not be read! Please send only text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 212.222.85.114 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[unixarea.de]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ARC_NA(0.00)[]; HAS_XAW(0.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; HAS_REPLYTO(0.00)[guru@unixarea.de]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; HAS_XOIP(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4V4yd75mddz44bL --bqtZ2oA6fjYMiWZP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit El día miércoles, marzo 27, 2024 a las 03:51:33p. m. +0100, Matthias Apitz escribió: > The WLAN card seems to be: > > none2@pci0:1:0:0: class=0x028000 rev=0x00 hdr=0x00 vendor=0x14c3 device=0x7961 subvendor=0x1a3b subdevice=0x4680 > vendor = 'MEDIATEK Corp.' > device = 'MT7921 802.11ax PCI Express Wireless Network Adapter' > class = network > > Perhaps not supported until today: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264300 While grepping through /usr/src I found the driver in /usr/src/sys/contrib/dev/mediatek/mt76/mt7921/ and a make && make install in # cd /usr/src/sys/modules/mt76 # make ... # make install ===> core (install) install -T release -o root -g wheel -m 555 mt76_core.ko /boot/modules/ kldxref /boot/modules ===> mt7915 (install) install -T release -o root -g wheel -m 555 if_mt7915.ko /boot/modules/ kldxref /boot/modules ===> mt7921 (install) install -T release -o root -g wheel -m 555 if_mt7921.ko /boot/modules/ kldxref /boot/modules installs it fine. There is also a manpage in /usr/src/share/man/man4/mt7921.4 (attached) I still have to build the firmware from ports/net/wifi-firmware-mt76-kmod. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --bqtZ2oA6fjYMiWZP Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="mt7921.4.txt" Content-Transfer-Encoding: 8bit MT7921(4) FreeBSD Kernel Interfaces Manual MT7921(4) NAME mt7921 – MediaTek IEEE 802.11ax wireless network driver SYNOPSIS The driver will auto-load without any user interaction using devmatch(8) if enabled in rc.conf(5). Only if auto-loading is explicitly disabled, place the following lines in rc.conf(5) to manually load the driver as a module at boot time: kld_list="${kld_list} if_mt7921" The driver should automatically load any firmware needed for the particular chipset. It is discouraged to load the driver from loader(8). DESCRIPTION The mt7921 driver is derived from MediaTek's Linux mt76 driver and provides support for the following chipsets: MediaTek MT7921E (PCIe) This driver requires firmware to be loaded before it will work. The package wifi-firmware-mt76-kmod from the ports/net/wifi-firmware-mt76-kmod port needs to be installed before the driver is loaded. Otherwise no wlan(4) interface can be created using ifconfig(8). The driver uses the linuxkpi_wlan and linuxkpi compat framework to bridge between the Linux and native FreeBSD driver code as well as to the native net80211(4) wireless stack. While mt7921 supports all 802.11 a/b/g/n/ac and ax the compatibility code currently only supports 802.11 a/b/g modes. Support for 802.11 n/ac is to come. BUGS Certainly. SEE ALSO wlan(4), ifconfig(8), wpa_supplicant(8) HISTORY The mt7921 driver first appeared in FreeBSD 14.0. FreeBSD 14.0-CURRENT April 18, 2023 FreeBSD 14.0-CURRENT --bqtZ2oA6fjYMiWZP-- From nobody Thu Mar 28 14:00:58 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 4V54vW725Cz5FwtG; Thu, 28 Mar 2024 14:01:11 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V54vW5H7Wz4dv2; Thu, 28 Mar 2024 14:01:11 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711634471; 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=Z8Fgz2To4xjvfyXPzn6/M3cC9GrXPIqXvsovM+n+AHs=; b=pH0KDm0QO8lB/W1lC2ZtXOfKYBwPQVITO4j3OHJW4PFBSrW26FtCqTzWlIVJpb2W1Ic3ld mgADovlLu7jpBagEmZLunSAzc5kv+QV2upTdeeKENAhYbaCNcKQoH+X3qrFAEOXDwa10Ge IYIUyXg6hKT4ximBpr2sKDAPSzrDOXmNWciy1uVr4QjYI4SMdQrGN71rYsiCjZ4JzZbXz7 iK1kKuWyZvjjH/PjcG26+gNiDYQjN/X71iRcAlCQH5XaozV83JpdsrISvQPWnA+Ek5KG+Q eoHaKOUW4VwYacSVfNzpZA+fBfGaNprlJoj+/GYTCQNcrhOiE2W92Xl0Np05UA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711634471; a=rsa-sha256; cv=none; b=Fzoy6IwH2uNNoDPDi4559ug/HDv7YlnLpmf1ae/q0P7jTTH8znz7Qv2KAQ3Sz8+21GH55n xxcGAyMa8Joy1USeb4OX8MkYNl1hIcCLKXe7EWBq8c4vZN7x+vhYpIPcNE4z3jEo9wvJzU QkTC54nHzch/YhT98rOjSNqfnR/Dr+a9uz96Xgvkbqr5XSU8o7e0rE3FC8fwFZh3/vuadD hyNcwSSOhMgRPXCcZHI5HH58fR+DpoNFh1bWmlMcCoJTICLVMmLWoUlXmxpsPE7ZTt/mJL J6R14GZ/9gU7Ny5/wtIaj6k3T4WS5gpGnyzGJURktXnEVXQrXxarLGKhiatEFA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711634471; 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=Z8Fgz2To4xjvfyXPzn6/M3cC9GrXPIqXvsovM+n+AHs=; b=F/8sL2RZPzzryWjH32+KXUGSqBhkhOuK71JLB+2rXooiZXm+pXuoZiXIxvUe2wvThAQrE1 stv0+4z4FRuHhMtvk15BWN/yF+iLP/BtDDEnFwnLylMPt73SM+69vQDI6Qfc1bwLdnl6ne EAkL+movyj/3G8dWuyUl7MYlvx8MVHWmco3lQ91/LaAdZHf36NaGf2RT6XxLyL3eBUykEu FLxXScq1nfgRYAwyf9kVOkDmslaO5Q4OHb1Dw+Y06aP/XgjIhtJAtktDKMw8/xYFUv2d1l 5ZyAYg9XQef87KMu9VgABwZtev9wFdrvUUqLEldRu8DcixG2muEl8sf4QGYzjw== Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4V54vW4nBZz1CVc; Thu, 28 Mar 2024 14:01:11 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-oi1-f178.google.com with SMTP id 5614622812f47-3c3ca3c3bbaso603313b6e.0; Thu, 28 Mar 2024 07:01:11 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVctPojx5j+jhNkb84XL3D0mGIAxAJ6MKg422EAxO0+KbfjKC6c8cL8+azwfkuZqOMldxbsf1qeMjuRRQk36+gmFoqrIZ1AmuNWHhj2jvnXefaR6gYKhqUO2XvdV76YcPlHHJH9o0np5d87rdaTSKAATvzL7laCthQV X-Gm-Message-State: AOJu0Yw+yS57fhvhKaDj0mh7qRVcjtPVpoBbXmK7qSMiftnHdoMVSF+R 3Wh93FWjv3NVMT2wmsewUoxqz/Pj9H+vFC9gynVZAxZcaZU9IL6crWM3d9AOFa8zQkaHJE6Ar6d N+th0BpZ5J8DfXUHB+lftLjmKorI= X-Google-Smtp-Source: AGHT+IEt4r3OmgtY+ivehZZtzjIaAoJwVNOTIfb5BfXb+zwUOuaYIBhBHJBZdmxzrayb2RrspRkC2+nNKXWqJFl4Y7s= X-Received: by 2002:a05:6808:dc7:b0:3c3:dddd:86b4 with SMTP id g7-20020a0568080dc700b003c3dddd86b4mr3083271oic.4.1711634470427; Thu, 28 Mar 2024 07:01:10 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <6e795e9c-8de4-4e02-9a96-8fabfaa4e66f@app.fastmail.com> <6047C8EF-B1B0-4286-93FA-AA38F8A18656@karels.net> <8031cd99-ded8-4b06-93b3-11cc729a8b2c@app.fastmail.com> <38c54399-6c96-44d8-a3a2-3cc1bfbe50c2@app.fastmail.com> <27d8144f-0658-46f6-b8f3-35eb60061644@lakerest.net> In-Reply-To: From: Nuno Teixeira Date: Thu, 28 Mar 2024 14:00:58 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Request for Testing: TCP RACK To: Drew Gallatin Cc: Konstantin Belousov , rrs , Mike Karels , tuexen , garyj@gmx.de, current@freebsd.org, net@freebsd.org, Randall Stewart Content-Type: multipart/alternative; boundary="000000000000986d170614b8f4a6" --000000000000986d170614b8f4a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all! Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop (amd64)! Thanks all! Drew Gallatin escreveu (quinta, 21/03/2024 =C3=A0(s) 12:58): > The entire point is to *NOT* go through the overhead of scheduling > something asynchronously, but to take advantage of the fact that a > user/kernel transition is going to trash the cache anyway. > > In the common case of a system which has less than the threshold number > of connections , we access the tcp_hpts_softclock function pointer, make > one function call, and access hpts_that_need_softclock, and then return. > So that's 2 variables and a function call. > > I think it would be preferable to avoid that call, and to move the > declaration of tcp_hpts_softclock and hpts_that_need_softclock so that th= ey > are in the same cacheline. Then we'd be hitting just a single line in th= e > common case. (I've made comments on the review to that effect). > > Also, I wonder if the threshold could get higher by default, so that hpts > is never called in this context unless we're to the point where we're > scheduling thousands of runs of the hpts thread (and taking all those clo= ck > interrupts). > > Drew > > On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Belousov wrote: > > On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote: > > Ok I have created > > > > https://reviews.freebsd.org/D44420 > > > > > > To address the issue. I also attach a short version of the patch that > Nuno > > can try and validate > > > > it works. Drew you may want to try this and validate the optimization > does > > kick in since I can > > > > only now test that it does not on my local box :) > The patch still causes access to all cpu's cachelines on each userret. > It would be much better to inc/check the threshold and only schedule the > call when exceeded. Then the call can occur in some dedicated context, > like per-CPU thread, instead of userret. > > > > > > > R > > > > > > > > On 3/18/24 3:42 PM, Drew Gallatin wrote: > > > No. The goal is to run on every return to userspace for every thread= . > > > > > > Drew > > > > > > On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote: > > > > On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote: > > > > > I got the idea from > > > > > > https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf > > > > > The gist is that the TCP pacing stuff needs to run frequently, an= d > > > > > rather than run it out of a clock interrupt, its more efficient t= o > run > > > > > it out of a system call context at just the point where we return > to > > > > > userspace and the cache is trashed anyway. The current > implementation > > > > > is fine for our workload, but probably not idea for a generic > system. > > > > > Especially one where something is banging on system calls. > > > > > > > > > > Ast's could be the right tool for this, but I'm super unfamiliar > with > > > > > them, and I can't find any docs on them. > > > > > > > > > > Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent > to > > > > > what's happening here? > > > > This call would need some AST number added, and then it registers t= he > > > > ast to run on next return to userspace, for the current thread. > > > > > > > > Is it enough? > > > > > > > > > > Drew > > > > > > > > > > > > > > On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote: > > > > > > On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > > > > > > > On 18 Mar 2024, at 7:04, tuexen@freebsd.org wrote: > > > > > > > > > > > > > > >> On 18. Mar 2024, at 12:42, Nuno Teixeira > > > > wrote: > > > > > > > >> > > > > > > > >> Hello all! > > > > > > > >> > > > > > > > >> It works just fine! > > > > > > > >> System performance is OK. > > > > > > > >> Using patch on main-n268841-b0aaf8beb126(-dirty). > > > > > > > >> > > > > > > > >> --- > > > > > > > >> net.inet.tcp.functions_available: > > > > > > > >> Stack D > > > > Alias PCB count > > > > > > > >> freebsd freebsd 0 > > > > > > > >> rack * > > > > rack 38 > > > > > > > >> --- > > > > > > > >> > > > > > > > >> It would be so nice that we can have a sysctl tunnable for > > > > this patch > > > > > > > >> so we could do more tests without recompiling kernel. > > > > > > > > Thanks for testing! > > > > > > > > > > > > > > > > @gallatin: can you come up with a patch that is acceptable > > > > for Netflix > > > > > > > > and allows to mitigate the performance regression. > > > > > > > > > > > > > > Ideally, tcphpts could enable this automatically when it > > > > starts to be > > > > > > > used (enough?), but a sysctl could select auto/on/off. > > > > > > There is already a well-known mechanism to request execution of > the > > > > > > specific function on return to userspace, namely AST. The > difference > > > > > > with the current hack is that the execution is requested for on= e > > > > callback > > > > > > in the context of the specific thread. > > > > > > > > > > > > Still, it might be worth a try to use it; what is the reason to > > > > hit a thread > > > > > > that does not do networking, with TCP processing? > > > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > Best regards > > > > > > > > Michael > > > > > > > >> > > > > > > > >> Thanks all! > > > > > > > >> Really happy here :) > > > > > > > >> > > > > > > > >> Cheers, > > > > > > > >> > > > > > > > >> Nuno Teixeira escreveu (domingo, > > > > 17/03/2024 =C3=A0(s) 20:26): > > > > > > > >>> > > > > > > > >>> Hello, > > > > > > > >>> > > > > > > > >>>> I don't have the full context, but it seems like the > > > > complaint is a performance regression in bonnie++ and perhaps other > > > > things when tcp_hpts is loaded, even when it is not used. Is that > > > > correct? > > > > > > > >>>> > > > > > > > >>>> If so, I suspect its because we drive the > > > > tcp_hpts_softclock() routine from userret(), in order to avoid tons > > > > of timer interrupts and context switches. To test this theory, yo= u > > > > could apply a patch like: > > > > > > > >>> > > > > > > > >>> It's affecting overall system performance, bonnie was jus= t > > > > a way to > > > > > > > >>> get some numbers to compare. > > > > > > > >>> > > > > > > > >>> Tomorrow I will test patch. > > > > > > > >>> > > > > > > > >>> Thanks! > > > > > > > >>> > > > > > > > >>> -- > > > > > > > >>> Nuno Teixeira > > > > > > > >>> FreeBSD Committer (ports) > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> -- > > > > > > > >> Nuno Teixeira > > > > > > > >> FreeBSD Committer (ports) > > > > > > > > > > > > > > > > > > > > > > > diff --git a/sys/netinet/tcp_hpts.c b/sys/netinet/tcp_hpts.c > > index 8c4d2d41a3eb..eadbee19f69c 100644 > > --- a/sys/netinet/tcp_hpts.c > > +++ b/sys/netinet/tcp_hpts.c > > @@ -216,6 +216,7 @@ struct tcp_hpts_entry { > > void *ie_cookie; > > uint16_t p_num; /* The hpts number one per cpu */ > > uint16_t p_cpu; /* The hpts CPU */ > > + uint8_t hit_callout_thresh; > > /* There is extra space in here */ > > /* Cache line 0x100 */ > > struct callout co __aligned(CACHE_LINE_SIZE); > > @@ -269,6 +270,11 @@ static struct hpts_domain_info { > > int cpu[MAXCPU]; > > } hpts_domains[MAXMEMDOM]; > > > > +counter_u64_t hpts_that_need_softclock; > > +SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, OID_AUTO, needsoftclock, > CTLFLAG_RD, > > + &hpts_that_need_softclock, > > + "Number of hpts threads that need softclock"); > > + > > counter_u64_t hpts_hopelessly_behind; > > > > SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, OID_AUTO, hopeless, > CTLFLAG_RD, > > @@ -334,7 +340,7 @@ SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, precision, > CTLFLAG_RW, > > &tcp_hpts_precision, 120, > > "Value for PRE() precision of callout"); > > SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, cnt_thresh, CTLFLAG_RW, > > - &conn_cnt_thresh, 0, > > + &conn_cnt_thresh, DEFAULT_CONNECTION_THESHOLD, > > "How many connections (below) make us use the callout based > mechanism"); > > SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, logging, CTLFLAG_RW, > > &hpts_does_tp_logging, 0, > > @@ -1548,6 +1554,9 @@ __tcp_run_hpts(void) > > struct tcp_hpts_entry *hpts; > > int ticks_ran; > > > > + if (counter_u64_fetch(hpts_that_need_softclock) =3D=3D 0) > > + return; > > + > > hpts =3D tcp_choose_hpts_to_run(); > > > > if (hpts->p_hpts_active) { > > @@ -1683,6 +1692,13 @@ tcp_hpts_thread(void *ctx) > > ticks_ran =3D tcp_hptsi(hpts, 1); > > tv.tv_sec =3D 0; > > tv.tv_usec =3D hpts->p_hpts_sleep_time * HPTS_TICKS_PER_SLOT; > > + if ((hpts->p_on_queue_cnt > conn_cnt_thresh) && > (hpts->hit_callout_thresh =3D=3D 0)) { > > + hpts->hit_callout_thresh =3D 1; > > + counter_u64_add(hpts_that_need_softclock, 1); > > + } else if ((hpts->p_on_queue_cnt <=3D conn_cnt_thresh) && > (hpts->hit_callout_thresh =3D=3D 1)) { > > + hpts->hit_callout_thresh =3D 0; > > + counter_u64_add(hpts_that_need_softclock, -1); > > + } > > if (hpts->p_on_queue_cnt >=3D conn_cnt_thresh) { > > if(hpts->p_direct_wake =3D=3D 0) { > > /* > > @@ -1818,6 +1834,7 @@ tcp_hpts_mod_load(void) > > cpu_top =3D NULL; > > #endif > > tcp_pace.rp_num_hptss =3D ncpus; > > + hpts_that_need_softclock =3D counter_u64_alloc(M_WAITOK); > > hpts_hopelessly_behind =3D counter_u64_alloc(M_WAITOK); > > hpts_loops =3D counter_u64_alloc(M_WAITOK); > > back_tosleep =3D counter_u64_alloc(M_WAITOK); > > @@ -2042,6 +2059,7 @@ tcp_hpts_mod_unload(void) > > free(tcp_pace.grps, M_TCPHPTS); > > #endif > > > > + counter_u64_free(hpts_that_need_softclock); > > counter_u64_free(hpts_hopelessly_behind); > > counter_u64_free(hpts_loops); > > counter_u64_free(back_tosleep); > > > > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000986d170614b8f4a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all!

Running rack @b7b= 78c1c169 "Optimize HPTS..." very happy on my laptop (amd64)!

Thanks all!

Drew Gallatin <gallatin@freebsd.org> escreveu (quinta, 21/= 03/2024 =C3=A0(s) 12:58):
The entir= e point is to *NOT* go through the overhead of scheduling something asynchr= onously, but to take advantage of the fact that a user/kernel transition is= going to trash the cache anyway.

In the commo= n case of a system which has less than the threshold=C2=A0 number of connec= tions , we access the tcp_hpts_softclock function pointer, make one functio= n call, and access hpts_that_need_softclock, and then return.=C2=A0 So that= 's 2 variables and a function call.

I thin= k it would be preferable to avoid that call, and to move the declaration of= tcp_hpts_softclock and hpts_that_need_softclock so that they are in the sa= me cacheline.=C2=A0 Then we'd be hitting just a single line in the comm= on case.=C2=A0 (I've made comments on the review to that effect).

Also, I wonder if the threshold could get higher by= default, so that hpts is never called in this context unless we're to = the point where we're scheduling thousands of runs of the hpts thread (= and taking all those clock interrupts).

Drew

On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Be= lousov wrote:
On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
> Ok I have created
>=C2=A0
>=C2=A0<= a href=3D"https://reviews.freebsd.org/D44420" target=3D"_blank">https://rev= iews.freebsd.org/D44420
>=C2=A0
>=C2= =A0
> To address the issue. I also attach a short version = of the patch that Nuno
> can try and validate
>=C2=A0
> it works. Drew you may want to try this and= validate the optimization does
> kick in since I can
<= /div>
>=C2=A0
> only now test that it does not on m= y local box :)
The patch still causes access to all cpu's= cachelines on each userret.
It would be much better to inc/c= heck the threshold and only schedule the
call when exceeded.= =C2=A0 Then the call can occur in some dedicated context,
lik= e per-CPU thread, instead of userret.

>=C2= =A0
>=C2=A0
> R
>=C2=A0<= br>
>=C2=A0
>=C2=A0
> On 3/1= 8/24 3:42 PM, Drew Gallatin wrote:
> > No.=C2=A0 The go= al is to run on every return to userspace for every thread.
&= gt; >=C2=A0
> > Drew
> >=C2=A0
> > On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belouso= v wrote:
> > > On Mon, Mar 18, 2024 at 03:13:11PM -0= 400, Drew Gallatin wrote:
> > > > I got the idea = from
> > > >=C2=A0https= ://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf
> > > > The gist is that the TCP pacing stuff needs to= run frequently, and
> > > > rather than run it o= ut of a clock interrupt, its more efficient to run
> > = > > it out of a system call context at just the point where we return= to
> > > > userspace and the cache is trashed an= yway. The current implementation
> > > > is fine = for our workload, but probably not idea for a generic system.
> > > > Especially one where something is banging on system ca= lls.
> > > >
> > > > As= t's could be the right tool for this, but I'm super unfamiliar with=
> > > > them, and I can't find any docs on t= hem.
> > > >
> > > > Wo= uld ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to
> > > > what's happening here?
> >= ; > This call would need some AST number added, and then it registers th= e
> > > ast to run on next return to userspace, for = the current thread.
> > >=C2=A0
> &= gt; > Is it enough?
> > > >
>= > > > Drew
> > >=C2=A0
> = > > >
> > > > On Mon, Mar 18, 2024, at 2= :33 PM, Konstantin Belousov wrote:
> > > > > O= n Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
&= gt; > > > > > On 18 Mar 2024, at 7:04,=C2=A0tuexen@freebsd.org wrote:
> > > > > >
> > > > &g= t; > >> On 18. Mar 2024, at 12:42, Nuno Teixeira
>= ; > > <ed= uardo@freebsd.org> wrote:
> > > > > >= ; >>
> > > > > > >> Hello all!<= br>
> > > > > > >>
> >= ; > > > > >> It works just fine!
> > = > > > > >> System performance is OK.
> &= gt; > > > > >> Using patch on main-n268841-b0aaf8beb126(-= dirty).
> > > > > > >>
= > > > > > > >> ---
> > > >= ; > > >> net.inet.tcp.functions_available:
> &= gt; > > > > >> Stack=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 D
> > >= ; Alias=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 PCB count
> > > > > >= >> freebsd freebsd=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 0
> > > > > > &= gt;> rack=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 *
> > > rack=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 38
> > > > > > >> ---
> > > > > > >>
> > > >= > > >> It would be so nice that we can have a sysctl tunnable = for
> > > this patch
> > > &g= t; > > >> so we could do more tests without recompiling kernel.=
> > > > > > > Thanks for testing!
> > > > > > >
> > > &g= t; > > > @gallatin: can you come up with a patch that is acceptabl= e
> > > for Netflix
> > > >= ; > > > and allows to mitigate the performance regression.
> > > > > >
> > > > >= > Ideally, tcphpts could enable this automatically when it
> > > starts to be
> > > > > > u= sed (enough?), but a sysctl could select auto/on/off.
> &g= t; > > > There is already a well-known mechanism to request execut= ion of the
> > > > > specific function on retu= rn to userspace, namely AST.=C2=A0 The difference
> > &= gt; > > with the current hack is that the execution is requested for = one
> > > callback
> > > >= > in the context of the specific thread.
> > > &= gt; >
> > > > > Still, it might be worth a = try to use it; what is the reason to
> > > hit a thr= ead
> > > > > that does not do networking, wit= h TCP processing?
> > > > >
>= > > > > >
> > > > > > Mike<= br>
> > > > > >
> > > &g= t; > > > Best regards
> > > > > > = > Michael
> > > > > > >>
=
> > > > > > >> Thanks all!
> = > > > > > >> Really happy here :)
> &= gt; > > > > >>
> > > > > >= ; >> Cheers,
> > > > > > >>
=
> > > > > > >> Nuno Teixeira <eduardo@freebsd.org&g= t; escreveu (domingo,
> > > 17/03/2024 =C3=A0(s) 20:= 26):
> > > > > > >>>
> > > > > > >>> Hello,
> > = > > > > >>>
> > > > > >= ; >>>> I don't have the full context, but it seems like the=
> > > complaint is a performance regression in bonn= ie++ and perhaps other
> > > things when tcp_hpts is= loaded, even when it is not used.=C2=A0 Is that
> > &g= t; correct?
> > > > > > >>>>
> > > > > > >>>> If so, I suspect= its because we drive the
> > > tcp_hpts_softclock()= routine from userret(), in order to avoid tons
> > >= ; of timer interrupts and context switches.=C2=A0 To test this theory,=C2= =A0 you
> > > could apply a patch like:
> > > > > > >>>
> > > &= gt; > > >>> It's affecting overall system performance, b= onnie was just
> > > a way to
> >= ; > > > > >>> get some numbers to compare.
> > > > > > >>>
> > > = > > > >>> Tomorrow I will test patch.
> = > > > > > >>>
> > > > >= ; > >>> Thanks!
> > > > > > >= ;>>
> > > > > > >>> --
> > > > > > >>> Nuno Teixeira
=
> > > > > > >>> FreeBSD Committer (ports)
> > > > > > >>
> >= > > > > >>
> > > > > > &= gt;>
> > > > > > >> --
> > > > > > >> Nuno Teixeira
> = > > > > > >> FreeBSD Committer (ports)
&= gt; > > > > >
> > > > >
> > >=C2=A0
> >=C2=A0
> diff --git a/sys/netinet/tcp_hpts.c b/sys/netinet/tcp_hpts= .c
> index 8c4d2d41a3eb..eadbee19f69c 100644
> --- a/sys/netinet/tcp_hpts.c
> +++ b/sys/netinet/tcp= _hpts.c
> @@ -216,6 +216,7 @@ struct tcp_hpts_entry {
<= /div>
>=C2=A0 void *ie_cookie;
>=C2=A0 uint16_t p= _num; /* The hpts number one per cpu */
>=C2=A0 uint16_t= p_cpu; /* The hpts CPU */
> + uint8_t hit_callout_thresh= ;
>=C2=A0 /* There is extra space in here */
>=C2=A0 /* Cache line 0x100 */
>=C2=A0 struct callo= ut co __aligned(CACHE_LINE_SIZE);
> @@ -269,6 +270,11 @@ s= tatic struct hpts_domain_info {
>=C2=A0 int cpu[MAXCPU];<= br>
>=C2=A0 } hpts_domains[MAXMEMDOM];
>=C2= =A0=C2=A0
> +counter_u64_t hpts_that_need_softclock;
> +SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, OID_AUTO, needs= oftclock, CTLFLAG_RD,
> +=C2=A0=C2=A0=C2=A0 &hpts_that= _need_softclock,
> +=C2=A0=C2=A0=C2=A0 "Number of hpt= s threads that need softclock");
> +
&g= t;=C2=A0 counter_u64_t hpts_hopelessly_behind;
>=C2=A0=C2= =A0
>=C2=A0 SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, O= ID_AUTO, hopeless, CTLFLAG_RD,
> @@ -334,7 +340,7 @@ SYSCT= L_INT(_net_inet_tcp_hpts, OID_AUTO, precision, CTLFLAG_RW,
&g= t;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &tcp_hpts_precision, 120,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Value for PRE() precision of cal= lout");
>=C2=A0 SYSCTL_INT(_net_inet_tcp_hpts, OID_AU= TO, cnt_thresh, CTLFLAG_RW,
> -=C2=A0=C2=A0=C2=A0 &con= n_cnt_thresh, 0,
> +=C2=A0=C2=A0=C2=A0 &conn_cnt_thres= h, DEFAULT_CONNECTION_THESHOLD,
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "How many connections (below) make us use the callout based mec= hanism");
>=C2=A0 SYSCTL_INT(_net_inet_tcp_hpts, OID_= AUTO, logging, CTLFLAG_RW,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= &hpts_does_tp_logging, 0,
> @@ -1548,6 +1554,9 @@ __t= cp_run_hpts(void)
>=C2=A0 struct tcp_hpts_entry *hpts;
>=C2=A0 int ticks_ran;
>=C2=A0=C2=A0
> + if (counter_u64_fetch(hpts_that_need_softclock) =3D=3D 0)
> + return;
> +
>=C2=A0 = hpts =3D tcp_choose_hpts_to_run();
>=C2=A0=C2=A0
>=C2=A0 if (hpts->p_hpts_active) {
> @@ -1683= ,6 +1692,13 @@ tcp_hpts_thread(void *ctx)
>=C2=A0 ticks_r= an =3D tcp_hptsi(hpts, 1);
>=C2=A0 tv.tv_sec =3D 0;
>=C2=A0 tv.tv_usec =3D hpts->p_hpts_sleep_time * HPTS_TICKS= _PER_SLOT;
> + if ((hpts->p_on_queue_cnt > conn_cnt_= thresh) && (hpts->hit_callout_thresh =3D=3D 0)) {
= > + hpts->hit_callout_thresh =3D 1;
> + counter_u6= 4_add(hpts_that_need_softclock, 1);
> + } else if ((hpts-&= gt;p_on_queue_cnt <=3D conn_cnt_thresh) && (hpts->hit_callout= _thresh =3D=3D 1)) {
> + hpts->hit_callout_thresh =3D = 0;
> + counter_u64_add(hpts_that_need_softclock, -1);
=
> + }
>=C2=A0 if (hpts->p_on_queue_cnt &= gt;=3D conn_cnt_thresh) {
>=C2=A0 if(hpts->p_direct_w= ake =3D=3D 0) {
>=C2=A0 /*
> @@ -1818,= 6 +1834,7 @@ tcp_hpts_mod_load(void)
>=C2=A0 cpu_top =3D = NULL;
>=C2=A0 #endif
>=C2=A0 tcp_pace.rp= _num_hptss =3D ncpus;
> + hpts_that_need_softclock =3D cou= nter_u64_alloc(M_WAITOK);
>=C2=A0 hpts_hopelessly_behind = =3D counter_u64_alloc(M_WAITOK);
>=C2=A0 hpts_loops =3D c= ounter_u64_alloc(M_WAITOK);
>=C2=A0 back_tosleep =3D coun= ter_u64_alloc(M_WAITOK);
> @@ -2042,6 +2059,7 @@ tcp_hpts_= mod_unload(void)
>=C2=A0 free(tcp_pace.grps, M_TCPHPTS);<= br>
>=C2=A0 #endif
>=C2=A0=C2=A0
> + counter_u64_free(hpts_that_need_softclock);
>=C2= =A0 counter_u64_free(hpts_hopelessly_behind);
>=C2=A0 co= unter_u64_free(hpts_loops);
>=C2=A0 counter_u64_free(back= _tosleep);





--
Nuno Teixeira
= FreeBSD Committer (ports)
--000000000000986d170614b8f4a6-- From nobody Thu Mar 28 15:53:35 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 4V57PS0PWyz5GBKB; Thu, 28 Mar 2024 15:53:48 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V57PR4qtzz4tK1; Thu, 28 Mar 2024 15:53:47 +0000 (UTC) (envelope-from tuexen@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (ip4d15f54e.dynamic.kabel-deutschland.de [77.21.245.78]) (Authenticated sender: micmac) by mail-n.franken.de (Postfix) with ESMTPSA id 36744721E2806; Thu, 28 Mar 2024 16:53:36 +0100 (CET) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Request for Testing: TCP RACK From: tuexen@freebsd.org In-Reply-To: Date: Thu, 28 Mar 2024 16:53:35 +0100 Cc: Drew Gallatin , Konstantin Belousov , rrs , Mike Karels , garyj@gmx.de, current@freebsd.org, net@freebsd.org, Randall Stewart Content-Transfer-Encoding: quoted-printable Message-Id: <5C9863F7-0F1C-4D02-9F6D-9DDC5FBEB368@freebsd.org> References: <6e795e9c-8de4-4e02-9a96-8fabfaa4e66f@app.fastmail.com> <6047C8EF-B1B0-4286-93FA-AA38F8A18656@karels.net> <8031cd99-ded8-4b06-93b3-11cc729a8b2c@app.fastmail.com> <38c54399-6c96-44d8-a3a2-3cc1bfbe50c2@app.fastmail.com> <27d8144f-0658-46f6-b8f3-35eb60061644@lakerest.net> To: Nuno Teixeira X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE] X-Rspamd-Queue-Id: 4V57PR4qtzz4tK1 > On 28. Mar 2024, at 15:00, Nuno Teixeira wrote: >=20 > Hello all! >=20 > Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop = (amd64)! >=20 > Thanks all! Thanks for the feedback! Best regards Michael >=20 > Drew Gallatin escreveu (quinta, 21/03/2024 = =C3=A0(s) 12:58): > The entire point is to *NOT* go through the overhead of scheduling = something asynchronously, but to take advantage of the fact that a = user/kernel transition is going to trash the cache anyway. >=20 > In the common case of a system which has less than the threshold = number of connections , we access the tcp_hpts_softclock function = pointer, make one function call, and access hpts_that_need_softclock, = and then return. So that's 2 variables and a function call. >=20 > I think it would be preferable to avoid that call, and to move the = declaration of tcp_hpts_softclock and hpts_that_need_softclock so that = they are in the same cacheline. Then we'd be hitting just a single line = in the common case. (I've made comments on the review to that effect). >=20 > Also, I wonder if the threshold could get higher by default, so that = hpts is never called in this context unless we're to the point where = we're scheduling thousands of runs of the hpts thread (and taking all = those clock interrupts). >=20 > Drew >=20 > On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Belousov wrote: >> On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote: >>> Ok I have created >>>=20 >>> https://reviews.freebsd.org/D44420 >>>=20 >>>=20 >>> To address the issue. I also attach a short version of the patch = that Nuno >>> can try and validate >>>=20 >>> it works. Drew you may want to try this and validate the = optimization does >>> kick in since I can >>>=20 >>> only now test that it does not on my local box :) >> The patch still causes access to all cpu's cachelines on each = userret. >> It would be much better to inc/check the threshold and only schedule = the >> call when exceeded. Then the call can occur in some dedicated = context, >> like per-CPU thread, instead of userret. >>=20 >>>=20 >>>=20 >>> R >>>=20 >>>=20 >>>=20 >>> On 3/18/24 3:42 PM, Drew Gallatin wrote: >>>> No. The goal is to run on every return to userspace for every = thread. >>>>=20 >>>> Drew >>>>=20 >>>> On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote: >>>>> On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote: >>>>>> I got the idea from >>>>>> = https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf >>>>>> The gist is that the TCP pacing stuff needs to run frequently, = and >>>>>> rather than run it out of a clock interrupt, its more efficient = to run >>>>>> it out of a system call context at just the point where we return = to >>>>>> userspace and the cache is trashed anyway. The current = implementation >>>>>> is fine for our workload, but probably not idea for a generic = system. >>>>>> Especially one where something is banging on system calls. >>>>>>=20 >>>>>> Ast's could be the right tool for this, but I'm super unfamiliar = with >>>>>> them, and I can't find any docs on them. >>>>>>=20 >>>>>> Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent = to >>>>>> what's happening here? >>>>> This call would need some AST number added, and then it registers = the >>>>> ast to run on next return to userspace, for the current thread. >>>>>=20 >>>>> Is it enough? >>>>>>=20 >>>>>> Drew >>>>>=20 >>>>>>=20 >>>>>> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote: >>>>>>> On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: >>>>>>>> On 18 Mar 2024, at 7:04, tuexen@freebsd.org wrote: >>>>>>>>=20 >>>>>>>>>> On 18. Mar 2024, at 12:42, Nuno Teixeira >>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> Hello all! >>>>>>>>>>=20 >>>>>>>>>> It works just fine! >>>>>>>>>> System performance is OK. >>>>>>>>>> Using patch on main-n268841-b0aaf8beb126(-dirty). >>>>>>>>>>=20 >>>>>>>>>> --- >>>>>>>>>> net.inet.tcp.functions_available: >>>>>>>>>> Stack D >>>>> Alias PCB count >>>>>>>>>> freebsd freebsd 0 >>>>>>>>>> rack * >>>>> rack 38 >>>>>>>>>> --- >>>>>>>>>>=20 >>>>>>>>>> It would be so nice that we can have a sysctl tunnable for >>>>> this patch >>>>>>>>>> so we could do more tests without recompiling kernel. >>>>>>>>> Thanks for testing! >>>>>>>>>=20 >>>>>>>>> @gallatin: can you come up with a patch that is acceptable >>>>> for Netflix >>>>>>>>> and allows to mitigate the performance regression. >>>>>>>>=20 >>>>>>>> Ideally, tcphpts could enable this automatically when it >>>>> starts to be >>>>>>>> used (enough?), but a sysctl could select auto/on/off. >>>>>>> There is already a well-known mechanism to request execution of = the >>>>>>> specific function on return to userspace, namely AST. The = difference >>>>>>> with the current hack is that the execution is requested for one >>>>> callback >>>>>>> in the context of the specific thread. >>>>>>>=20 >>>>>>> Still, it might be worth a try to use it; what is the reason to >>>>> hit a thread >>>>>>> that does not do networking, with TCP processing? >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Mike >>>>>>>>=20 >>>>>>>>> Best regards >>>>>>>>> Michael >>>>>>>>>>=20 >>>>>>>>>> Thanks all! >>>>>>>>>> Really happy here :) >>>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>>=20 >>>>>>>>>> Nuno Teixeira escreveu (domingo, >>>>> 17/03/2024 =C3=A0(s) 20:26): >>>>>>>>>>>=20 >>>>>>>>>>> Hello, >>>>>>>>>>>=20 >>>>>>>>>>>> I don't have the full context, but it seems like the >>>>> complaint is a performance regression in bonnie++ and perhaps = other >>>>> things when tcp_hpts is loaded, even when it is not used. Is that >>>>> correct? >>>>>>>>>>>>=20 >>>>>>>>>>>> If so, I suspect its because we drive the >>>>> tcp_hpts_softclock() routine from userret(), in order to avoid = tons >>>>> of timer interrupts and context switches. To test this theory, = you >>>>> could apply a patch like: >>>>>>>>>>>=20 >>>>>>>>>>> It's affecting overall system performance, bonnie was just >>>>> a way to >>>>>>>>>>> get some numbers to compare. >>>>>>>>>>>=20 >>>>>>>>>>> Tomorrow I will test patch. >>>>>>>>>>>=20 >>>>>>>>>>> Thanks! >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Nuno Teixeira >>>>>>>>>>> FreeBSD Committer (ports) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Nuno Teixeira >>>>>>>>>> FreeBSD Committer (ports) >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>=20 >>=20 >>> diff --git a/sys/netinet/tcp_hpts.c b/sys/netinet/tcp_hpts.c >>> index 8c4d2d41a3eb..eadbee19f69c 100644 >>> --- a/sys/netinet/tcp_hpts.c >>> +++ b/sys/netinet/tcp_hpts.c >>> @@ -216,6 +216,7 @@ struct tcp_hpts_entry { >>> void *ie_cookie; >>> uint16_t p_num; /* The hpts number one per cpu */ >>> uint16_t p_cpu; /* The hpts CPU */ >>> + uint8_t hit_callout_thresh; >>> /* There is extra space in here */ >>> /* Cache line 0x100 */ >>> struct callout co __aligned(CACHE_LINE_SIZE); >>> @@ -269,6 +270,11 @@ static struct hpts_domain_info { >>> int cpu[MAXCPU]; >>> } hpts_domains[MAXMEMDOM]; >>>=20 >>> +counter_u64_t hpts_that_need_softclock; >>> +SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, OID_AUTO, = needsoftclock, CTLFLAG_RD, >>> + &hpts_that_need_softclock, >>> + "Number of hpts threads that need softclock"); >>> + >>> counter_u64_t hpts_hopelessly_behind; >>>=20 >>> SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, OID_AUTO, hopeless, = CTLFLAG_RD, >>> @@ -334,7 +340,7 @@ SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, = precision, CTLFLAG_RW, >>> &tcp_hpts_precision, 120, >>> "Value for PRE() precision of callout"); >>> SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, cnt_thresh, CTLFLAG_RW, >>> - &conn_cnt_thresh, 0, >>> + &conn_cnt_thresh, DEFAULT_CONNECTION_THESHOLD, >>> "How many connections (below) make us use the callout based = mechanism"); >>> SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, logging, CTLFLAG_RW, >>> &hpts_does_tp_logging, 0, >>> @@ -1548,6 +1554,9 @@ __tcp_run_hpts(void) >>> struct tcp_hpts_entry *hpts; >>> int ticks_ran; >>>=20 >>> + if (counter_u64_fetch(hpts_that_need_softclock) =3D=3D 0) >>> + return; >>> + >>> hpts =3D tcp_choose_hpts_to_run(); >>>=20 >>> if (hpts->p_hpts_active) { >>> @@ -1683,6 +1692,13 @@ tcp_hpts_thread(void *ctx) >>> ticks_ran =3D tcp_hptsi(hpts, 1); >>> tv.tv_sec =3D 0; >>> tv.tv_usec =3D hpts->p_hpts_sleep_time * HPTS_TICKS_PER_SLOT; >>> + if ((hpts->p_on_queue_cnt > conn_cnt_thresh) && = (hpts->hit_callout_thresh =3D=3D 0)) { >>> + hpts->hit_callout_thresh =3D 1; >>> + counter_u64_add(hpts_that_need_softclock, 1); >>> + } else if ((hpts->p_on_queue_cnt <=3D conn_cnt_thresh) && = (hpts->hit_callout_thresh =3D=3D 1)) { >>> + hpts->hit_callout_thresh =3D 0; >>> + counter_u64_add(hpts_that_need_softclock, -1); >>> + } >>> if (hpts->p_on_queue_cnt >=3D conn_cnt_thresh) { >>> if(hpts->p_direct_wake =3D=3D 0) { >>> /* >>> @@ -1818,6 +1834,7 @@ tcp_hpts_mod_load(void) >>> cpu_top =3D NULL; >>> #endif >>> tcp_pace.rp_num_hptss =3D ncpus; >>> + hpts_that_need_softclock =3D counter_u64_alloc(M_WAITOK); >>> hpts_hopelessly_behind =3D counter_u64_alloc(M_WAITOK); >>> hpts_loops =3D counter_u64_alloc(M_WAITOK); >>> back_tosleep =3D counter_u64_alloc(M_WAITOK); >>> @@ -2042,6 +2059,7 @@ tcp_hpts_mod_unload(void) >>> free(tcp_pace.grps, M_TCPHPTS); >>> #endif >>>=20 >>> + counter_u64_free(hpts_that_need_softclock); >>> counter_u64_free(hpts_hopelessly_behind); >>> counter_u64_free(hpts_loops); >>> counter_u64_free(back_tosleep); >>=20 >>=20 >=20 >=20 >=20 > --=20 > Nuno Teixeira > FreeBSD Committer (ports) From nobody Fri Mar 29 15:52:55 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 4V5lMT64DHz5Dc7H for ; Fri, 29 Mar 2024 15:54:13 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V5lMT0D7Sz4N4v; Fri, 29 Mar 2024 15:54:13 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=TTbwRGXt; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1711727629; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=gZftsw/W+dDARuHQ0w/mt9mb8A6HbPFPraUTyNBlP8k=; b=TTbwRGXtMHnEiUG2ELIbBrCwYqy+d3me4cRcclCoUn+/tQhRTDR7zlpccpn/aB5pcosCZb 5OirVfDHcNQzIsCznJ8RNUV7QnY9sN8GjPzlCQNqBjt/yjUPA2IWYdv186MrBX6yUpZagY NDt/CXHhXCrzjtXajNv9IbWIHvCbJ1TBZm7MLlm1/WWs3rd4+ksKLL5TINrj/BFbmvaNxf Dur7QDb3JTyMeliYT/BhhXP7BdP+koWqIJA09BZS97CMpeHkcb6ja9BKyWHaBEcv3MTyd7 vM5o6hOe9SczIF+vSMy2Reh0kVw6LcjAwjCnfSLSChVpOIom7Xc1sg2J4I++nA== Date: Fri, 29 Mar 2024 16:52:55 +0100 From: Alexander Leidinger To: Current , bnovkov@FreeBSD.org Subject: Multiple issues with current (kldload failures, missing CTF stuff, pty issues, ...) Message-ID: <09ef22679b76cb2dbeace8e78bf9f80e@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_14c9a787fb6275db952b576fe533277e"; micalg=pgp-sha256 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.06 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.961]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; HAS_ORG_HEADER(0.00)[]; HAS_ATTACHMENT(0.00)[]; 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_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current@freebsd.org]; DKIM_TRACE(0.00)[leidinger.net:+] X-Rspamd-Queue-Id: 4V5lMT0D7Sz4N4v This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_14c9a787fb6275db952b576fe533277e Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, sources from 2024-03-11 work. Sources from 2024-03-25 and today don't work (see below for the issue). As the monthly stabilisation pass didn't find obvious issues, it is something related to my setup: - not a generic kernel - very modular kernel (as much as possible as a module) - bind_now (a build without fails too, tested with clean /usr/obj) - ccache (a build without fails too, tested with clean /usr/obj) - kernel retpoline (build without in progress) - userland retpoline (build without in progress) - kernel build with WITH_CTF / DDB_CTF (next one to test if it isn't retpoline) - -fno-builtin - CPUFLAGS=native (except for stuff in /usr/src/sys/boot) - malloc production - COPTFLAGS= -O2 -pipe The issue is, that kernel modules load OK from loader, but once it starts init any module fails to load (e.g. via autodetection of hardware or rc.conf kld_list) with the message that the kernel and module versions are out of sync and the module refuses to load. I tried the workaround to load the modules from the loader, which works, but then I can't login remotely as ssh fails to allocate a pty. By loading modules via the loader, I can see messages about missing CTF info when the nvidia modules (from ports = not yet rebuild = in /boot/modules/...ko instead of /boot/kernel/...ko) try to get initialised... and it looks like they are failing to get initialised because of this missing CTF stuff (I'm back to the previous boot env to be able to login remotely and send mails, I don't have a copy of the failure message at hand). I assume the missing CTF stuff is due to the CTF based pretty printing (https://cgit.freebsd.org/src/commit/?id=c21bc6f3c2425de74141bfee07b609bf65b5a6b3). Is this supposed to fail to load modules which are compiled without CTF data? Shouldn't this work gracefully (e.g. spit out a warning that pretty printing is not available for module X and have the module working)? Next steps: - try a world without retpoline (bind_now and ccache active) - try a kernel without CTF (bind now, ccache, retpoline active) - try a world without bind_now, retpoline, CTF, CPUFLAGS, COPTFLAGS If anyone has an idea how to debug this in some other way... Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_14c9a787fb6275db952b576fe533277e Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmYG4+sACgkQEg2wmwP4 2IZ9Aw//XUOLP9lAu3PuQEHkvcRr/lz+AZsLxxaWNWlBDEXexLnIMRe0Yc0N0J2l wQwtLUKSBkxHFLYb6zvb4fnnt5ydKiUo1P/BRhf3UtNFw2hiuX7/9uEf+QRTpsmF MHnqsHkg1gRFOrH2D/iVPwmsllnlMWe7D7AP57Cck2ZCmFc/PX+d4B8nMlRTTjOJ phEsfY7izcQTX4jymrx+OhKV2wLXExLKDeuzRRKYuGY1hUp3HmA28EMduClndqVB 64xVoqWwgW4XlzFpRFLoAOOOw02ZFmKcEVBBNNUfbogT6mxOWWp7lpOMj/dtaatl hE0dS5i4sDU8U5atFFK6agnyEC46osCUNtu51l8mv41qKzq+8fg8HaDZllUnpkyt ffh4BLYPY1MKms6mla+6pOG5pVlF+IZZMH3cimCCkc2ub+pmlLQtRJ7ewp8aDyx1 aWlEREB2k5XxcRbQFPbOhPcxq52P8oIUTnj+8mbOLnZbDSDHaZyZowg/nYYjnXc+ Xnu/YwCSvvFzZ9zj6KbsaGDXqPcGOCq51vNP7wxneQO1QxiOHBVwvCCiZKDHtvfT 1YvfT7d+5OREkeolJH4mHMrMOgzJ/dezV8TCDPI2IADWTBluxzjU+3tf35APDJNx nKfDZZ/0f9TMrQm9FQqR6IkjL6tH0szMM8cXV/H5dSQvuBOKR28= =x0qD -----END PGP SIGNATURE----- --=_14c9a787fb6275db952b576fe533277e-- From nobody Fri Mar 29 17:13:39 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 4V5n7D4K3wz5FGLJ for ; Fri, 29 Mar 2024 17:13:44 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V5n7D2SnMz4Xmh; Fri, 29 Mar 2024 17:13:44 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x232.google.com with SMTP id 5614622812f47-3c396fec63aso830152b6e.0; Fri, 29 Mar 2024 10:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711732422; x=1712337222; 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=iEAJvbul+GSsKRL8coz6NxLrYCNn7hgnYbfpUbWYW48=; b=MR8EWNKUKyJn1y73PAfFI9Izfqu24/90QTsynC/Y2NoQF+WVv9ow+0JRFCQkrQ0BFk iWpGOT+tK+yfg1c3JsYDAp6C+MtbDoLZhxVT/SZ6M62J1UzQfWHiblrE1YyS6c6gJabF zVsnsLw46sD1jypWmlui0TJi5DV0GFQMHfUyQl3LS/kzBN3fxMMfFscaV0FFTUCm9Mfp Ji7CkKrgG/hWsmRRzFR4qu1ZEtp/2s0KMO9sEr78uWqi1mwLAoe+p6U8iJ/73KMhnWh1 FSVkm+8RQuyi5PzzHya8JFbe2PVlkdGoYgtt2AiB+7qMGsl/0q1vD0vcK3xKGtZ0Z4dD LI9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711732422; x=1712337222; 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=iEAJvbul+GSsKRL8coz6NxLrYCNn7hgnYbfpUbWYW48=; b=cjJ+mD9dWf5lBw2eLccLl+frbc0mzQpG21tFmn7ZRTm3mz9GhxBJ2cDz4VFNkjdhEX YDqozdfw25D4RUZAh5St0a0TZgftRyaTUnB/7PrFG8yHYjhk8BaIQW4gltX327MBjgbg iwWYesEkJpwuo4GpRVojZm/DUtr7Ob28M5bzfDCRGJ1E819kc/jw0XkYyo7DGzuVE5cx Av2Ee78lLFWDoF7b4Rj2d5UCMXJgu8h1blzmgBuglQkFTD+GwFw5WCMziUaJ01XK7W91 9mlCdp3VQ/mUGg2T2DjT4k/O8UAebot7wVqRgeemMmu53d1G3NPGmnrmRTnDMQkSxhKn IDiA== X-Forwarded-Encrypted: i=1; AJvYcCWni72l7RMq/nq0+SM8iVSxfemOnQkyE5Pbkl3kL0MX0/a2KWsptvwIHTIiqQRD9AybYqNntjbqQPPh/Ohj0Vd6t2mo X-Gm-Message-State: AOJu0Yx4kmPeTCTX0k39cyzu92wOA5XG7Tt+CGwsjc9d/WEnYeO/OSWZ IRhVTuKqFca7c2x1MXw0LAaijo0RTjmcUdEJ8ezVDQtxUH8HnX/qMqyKG/AI X-Google-Smtp-Source: AGHT+IGhh+r4Jok/XSiFeUUmUoTimoc328yRFxe9jAwn5QVgWBVtNpDbCi0lWB7/kAPzl0Sf3Jr0Vg== X-Received: by 2002:a05:6808:2907:b0:3c3:e0c9:e5ef with SMTP id ev7-20020a056808290700b003c3e0c9e5efmr2305860oib.59.1711732422607; Fri, 29 Mar 2024 10:13:42 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id jt12-20020a05621427ec00b00696766401adsm1819723qvb.38.2024.03.29.10.13.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Mar 2024 10:13:42 -0700 (PDT) Date: Fri, 29 Mar 2024 13:13:39 -0400 From: Mark Johnston To: Alexander Leidinger Cc: Current , bnovkov@freebsd.org Subject: Re: Multiple issues with current (kldload failures, missing CTF stuff, pty issues, ...) Message-ID: References: <09ef22679b76cb2dbeace8e78bf9f80e@Leidinger.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09ef22679b76cb2dbeace8e78bf9f80e@Leidinger.net> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4V5n7D2SnMz4Xmh On Fri, Mar 29, 2024 at 04:52:55PM +0100, Alexander Leidinger wrote: > Hi, > > sources from 2024-03-11 work. Sources from 2024-03-25 and today don't work > (see below for the issue). As the monthly stabilisation pass didn't find > obvious issues, it is something related to my setup: > - not a generic kernel > - very modular kernel (as much as possible as a module) > - bind_now (a build without fails too, tested with clean /usr/obj) > - ccache (a build without fails too, tested with clean /usr/obj) > - kernel retpoline (build without in progress) > - userland retpoline (build without in progress) > - kernel build with WITH_CTF / DDB_CTF (next one to test if it isn't > retpoline) > - -fno-builtin > - CPUFLAGS=native (except for stuff in /usr/src/sys/boot) > - malloc production > - COPTFLAGS= -O2 -pipe > > The issue is, that kernel modules load OK from loader, but once it starts > init any module fails to load (e.g. via autodetection of hardware or rc.conf > kld_list) with the message that the kernel and module versions are out of > sync and the module refuses to load. What is the exact revision you're running? There were some unrelated changes to the kernel linker around the same time. > I tried the workaround to load the modules from the loader, which works, but > then I can't login remotely as ssh fails to allocate a pty. By loading > modules via the loader, I can see messages about missing CTF info when the > nvidia modules (from ports = not yet rebuild = in /boot/modules/...ko > instead of /boot/kernel/...ko) try to get initialised... and it looks like > they are failing to get initialised because of this missing CTF stuff (I'm > back to the previous boot env to be able to login remotely and send mails, I > don't have a copy of the failure message at hand). > > I assume the missing CTF stuff is due to the CTF based pretty printing (https://cgit.freebsd.org/src/commit/?id=c21bc6f3c2425de74141bfee07b609bf65b5a6b3). > Is this supposed to fail to load modules which are compiled without CTF > data? Shouldn't this work gracefully (e.g. spit out a warning that pretty > printing is not available for module X and have the module working)? >From my reading of linker_ctf_load_file(), this is exactly how it already works. > Next steps: > - try a world without retpoline (bind_now and ccache active) > - try a kernel without CTF (bind now, ccache, retpoline active) > - try a world without bind_now, retpoline, CTF, CPUFLAGS, COPTFLAGS > > If anyone has an idea how to debug this in some other way... > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Fri Mar 29 17:21:49 2024 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4V5nK56h4fz5FHPw for ; Fri, 29 Mar 2024 17:22:17 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V5nK461D4z4ZRq; Fri, 29 Mar 2024 17:22:16 +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=1711732928; 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=KQqNXBY5fhhp7Oyu2kMvakyDziOO18G+zFHJjhEgNsU=; b=A9vQobdJfEJ1HjA9yefDB3R8V4T6DyxX/8r/bZZs1gMGB7jhFKKMSYBNpPJ5X0S7E5C/FJ WDseyTc+pRBfW3NIVRDYfcqlOHW5ZfoxpPKCuOexzQLgtyHVrWMT5wf8txUwitX4izzxc5 OWx7gdztKip1vn/pezF3wejgw9iMU/sQIQ78Ypmkp+P7fb85aub5IxUt85KAwcqakX2PWZ KujMcP1SQxPBA4bppTd/bocTpiAeyL8CxnIwWELkDyAC8lwKXv31Bsw2RWSkDZl8qWfTjf FrmKL0Elt/HnsSV9BEzQ1nwwYUWonpXIlcsuv37d5B1Scc67W+nZ5KkmI2hgnQ== Date: Fri, 29 Mar 2024 18:21:49 +0100 From: Alexander Leidinger To: Mark Johnston Cc: Current , bnovkov@freebsd.org Subject: Re: Multiple issues with current (kldload failures, missing CTF stuff, pty issues, ...) In-Reply-To: References: <09ef22679b76cb2dbeace8e78bf9f80e@Leidinger.net> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_aa724c7385a7df80ae67412cbe3a96a1"; micalg=pgp-sha256 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Queue-Id: 4V5nK461D4z4ZRq This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_aa724c7385a7df80ae67412cbe3a96a1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-03-29 18:13, schrieb Mark Johnston: > On Fri, Mar 29, 2024 at 04:52:55PM +0100, Alexander Leidinger wrote: >> Hi, >> >> sources from 2024-03-11 work. Sources from 2024-03-25 and today don't >> work >> (see below for the issue). As the monthly stabilisation pass didn't >> find >> obvious issues, it is something related to my setup: >> - not a generic kernel >> - very modular kernel (as much as possible as a module) >> - bind_now (a build without fails too, tested with clean /usr/obj) >> - ccache (a build without fails too, tested with clean /usr/obj) >> - kernel retpoline (build without in progress) >> - userland retpoline (build without in progress) >> - kernel build with WITH_CTF / DDB_CTF (next one to test if it isn't >> retpoline) >> - -fno-builtin >> - CPUFLAGS=native (except for stuff in /usr/src/sys/boot) >> - malloc production >> - COPTFLAGS= -O2 -pipe >> >> The issue is, that kernel modules load OK from loader, but once it >> starts >> init any module fails to load (e.g. via autodetection of hardware or >> rc.conf >> kld_list) with the message that the kernel and module versions are out >> of >> sync and the module refuses to load. > > What is the exact revision you're running? There were some unrelated > changes to the kernel linker around the same time. The working src is from 2024-03-11-094351 (GMT+0100). The failing src was fetched after Glebs stabilization week message (and todays src before the sound stuff still fails). Retpoline wasn't the cause, next test is the CTF stuff in the kernel... >> I tried the workaround to load the modules from the loader, which >> works, but >> then I can't login remotely as ssh fails to allocate a pty. By loading >> modules via the loader, I can see messages about missing CTF info when >> the >> nvidia modules (from ports = not yet rebuild = in /boot/modules/...ko >> instead of /boot/kernel/...ko) try to get initialised... and it looks >> like >> they are failing to get initialised because of this missing CTF stuff >> (I'm >> back to the previous boot env to be able to login remotely and send >> mails, I >> don't have a copy of the failure message at hand). >> >> I assume the missing CTF stuff is due to the CTF based pretty printing >> (https://cgit.freebsd.org/src/commit/?id=c21bc6f3c2425de74141bfee07b609bf65b5a6b3). >> Is this supposed to fail to load modules which are compiled without >> CTF >> data? Shouldn't this work gracefully (e.g. spit out a warning that >> pretty >> printing is not available for module X and have the module working)? > > From my reading of linker_ctf_load_file(), this is exactly how it > already works. Great that it works this way, I still suggest to print a message what the warning about missing stuff means. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_aa724c7385a7df80ae67412cbe3a96a1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmYG+LwACgkQEg2wmwP4 2IYibQ//TvySR3GshoWYEEUNmgfAzE1Cy5HvdDW4C89JzoSmDa9LLeLuxsQhd/pY pxrxJss7EkbawMAoq41p4N36MD+QbsQ1GAZK72VMVHRMCrXCDsDWoS0oyqhsvBsm bOWYnadh7avxj+mhgexhAdPShrbuNVcGihxu+CyAnQ5zmWfgZLjndhkWzroJPBRs eCvaAjvn5J24IbGGnOevMdmmbotMCpgU7IcFXpIt7aDtyJJ75INlyVqvgQ2gAyMu /YiarcXCWf/EhyGCNpKrdZO7GaE6D81ZNpXGpUaCyzZRBm3X4jeINJXcCmHnQh2O ptf9Q/1kjhLAHybgM9PFZMRcipODaXX/cki7ShRB0Y4G7WLwMy7l/45NfMdoe/7y HvGOuzARfEFNRQco5Fw08JQzWpP2nc95IhjbDDDqnRlxepLAcy7PjNVurD0sMrwg PZhOWeVomO0jUSeR9X4x0Km0p/gHNJvrBukOBKLhebsESwxp/JSRAQI8zxhTkY2D +Ao1HVX0qeTWEyfwlxflWhVEG4K9g5VgNdE+dekY80e+DmRKBbsGZKjRwdDHf3UG mcVx5XEZOPnsJYGiit9VtNNPBzCzUcyt80V+hbf8oCd5GsTGXeFC2pKO8L6tRR7S ogcUtFw+EKSPRAiih1SC3RtqlXB9xvzk3CIYyU+0HRCX2GjUQ04= =JLhz -----END PGP SIGNATURE----- --=_aa724c7385a7df80ae67412cbe3a96a1-- From nobody Fri Mar 29 18:43:40 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 4V5q731WPLz5FSCs for ; Fri, 29 Mar 2024 18:43:43 +0000 (UTC) (envelope-from bojan.novkovic@kset.org) Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V5q726rkzz4r8Y for ; Fri, 29 Mar 2024 18:43:42 +0000 (UTC) (envelope-from bojan.novkovic@kset.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-a44ad785a44so265723366b.3 for ; Fri, 29 Mar 2024 11:43:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711737821; x=1712342621; h=content-transfer-encoding:in-reply-to:autocrypt:from:cc:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nlU302bSgVlbmp6HYPZ9pMeDuhDjZZft13jand9Du1s=; b=KlkgpTizGRF0WD54LOiEGp3yZa9KhaFcHVxGEOHEGvCIRJtdTueCeprF49F9FGa3/x ubAbLmGejO/0CbsLVbFKPJaWWsO4lnfet7fWtxVxtcoXGdNMhMwsc2JJxJIeHpJcf3ga AiC5uST4SE8iDOQsNkFk1T0e2YqmfYXw4vs15La6GHKS2MT11vJ0wY1XSoVfQCGNkUMd mtnHMnjYI+C6GdAfLWrM5wvaMkH7A+YRK62tV1Ij27c9hjLq/MBUg3xHwbbPsOaQ8Zkn ZnHA/FD/+PXRwPUUtbXgqWzUbdUoADWApYxAyba6oIRjphXP81x1z7hm/pIka1XGxoJL k+MA== X-Gm-Message-State: AOJu0Yw6qDPaG5vRF32SAqgD/SI6kX28e180MYq2Y5dJXHs4IYe6TTgh fypSsoIKu1wgcFI7aIfvoat3xvLaES7rYCBFslc8Po4aaNqnMoCPVyVVy8qzFJJEbt/dBGtp8UP 4 X-Google-Smtp-Source: AGHT+IGGkf42m6fE2/KjnVxFkvuhfwJjHLszsidn3VbhuYD25XKLUj7JzvqRHqGF7W68mzpp/h31Og== X-Received: by 2002:a17:906:e8b:b0:a4e:eab:a8c1 with SMTP id p11-20020a1709060e8b00b00a4e0eaba8c1mr2184993ejf.33.1711737821051; Fri, 29 Mar 2024 11:43:41 -0700 (PDT) Received: from [192.168.0.91] ([109.60.96.219]) by smtp.gmail.com with ESMTPSA id x18-20020a1709060a5200b00a46ab3adea5sm2209603ejf.113.2024.03.29.11.43.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Mar 2024 11:43:40 -0700 (PDT) Message-ID: <9dce6c42-0236-447c-b78b-dd03adff6eaa@freebsd.org> Date: Fri, 29 Mar 2024 19:43:40 +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: Multiple issues with current (kldload failures, missing CTF stuff, pty issues, ...) Content-Language: en-US To: Alexander Leidinger References: <09ef22679b76cb2dbeace8e78bf9f80e@Leidinger.net> Cc: Current From: =?UTF-8?Q?Bojan_Novkovi=C4=87?= Autocrypt: addr=bnovkov@freebsd.org; keydata= xjMEZdIQsxYJKwYBBAHaRw8BAQdA/V2uVmdN7VY2Ps8wDgLlWU3b9+kPdg9bf+FHgEEX49TN JUJvamFuIE5vdmtvdmnEhyA8Ym5vdmtvdkBGcmVlQlNELm9yZz7CmQQTFgoAQRYhBLAb6L2d hfD6hKflVB43npi7IZ8rBQJl0hCzAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMBAh4H AheAAAoJEB43npi7IZ8rzb0A/0aY3c/XubbtQzNyA0xzyKNZlDc9zesxEMVi6rOAZNz/AQC2 QmBTBEcbyOKDfJ5m02LpudVi9thZxlrr2n0ZX9kgA844BGXSELMSCisGAQQBl1UBBQEBB0Dn 3m+8g7KTp3yC4CLICis/CIonFfNqQcJOVv6Gd73adQMBCAfCfgQYFgoAJhYhBLAb6L2dhfD6 hKflVB43npi7IZ8rBQJl0hCzAhsMBQkFo5qAAAoJEB43npi7IZ8ruPcBAJM5wq5j64RFu4sc zrryK4FeCTt/Xhfyn3UhT2hHuYkPAQDWHDN6XZ097C5wUkWUr8ywHDlMM5gWIDbr9TMUudoc Aw== In-Reply-To: <09ef22679b76cb2dbeace8e78bf9f80e@Leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4V5q726rkzz4r8Y On 3/29/24 16:52, Alexander Leidinger wrote: > Hi, > > sources from 2024-03-11 work. Sources from 2024-03-25 and today don't > work (see below for the issue). As the monthly stabilisation pass > didn't find obvious issues, it is something related to my setup: >  - not a generic kernel >  - very modular kernel (as much as possible as a module) >  - bind_now (a build without fails too, tested with clean /usr/obj) >  - ccache (a build without fails too, tested with clean /usr/obj) >  - kernel retpoline (build without in progress) >  - userland retpoline (build without in progress) >  - kernel build with WITH_CTF / DDB_CTF (next one to test if it isn't > retpoline) >  - -fno-builtin >  - CPUFLAGS=native (except for stuff in /usr/src/sys/boot) >  - malloc production >  - COPTFLAGS= -O2 -pipe > > The issue is, that kernel modules load OK from loader, but once it > starts init any module fails to load (e.g. via autodetection of > hardware or rc.conf kld_list) with the message that the kernel and > module versions are out of sync and the module refuses to load. > > I tried the workaround to load the modules from the loader, which > works, but then I can't login remotely as ssh fails to allocate a pty. > By loading modules via the loader, I can see messages about missing > CTF info when the nvidia modules (from ports = not yet rebuild = in > /boot/modules/...ko instead of /boot/kernel/...ko) try to get > initialised... and it looks like they are failing to get initialised > because of this missing CTF stuff (I'm back to the previous boot env > to be able to login remotely and send mails, I don't have a copy of > the failure message at hand). > > I assume the missing CTF stuff is due to the CTF based pretty printing > (https://cgit.freebsd.org/src/commit/?id=c21bc6f3c2425de74141bfee07b609bf65b5a6b3). > Is this supposed to fail to load modules which are compiled without > CTF data? Shouldn't this work gracefully (e.g. spit out a warning that > pretty printing is not available for module X and have the module > working)? > This is indeed how it works, those messages are emitted by CTF loading routines in 'kern/kern_ctf.c' as a warning and do not affect the rest of the module loading process. However, I completely agree that they are cryptic and spammy, I'll try to do something about that. Bojan From nobody Sat Mar 30 02:02:37 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 4V60sm2v6Lz5FrGp for ; Sat, 30 Mar 2024 02:02:52 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V60sl5lrwz4rSh for ; Sat, 30 Mar 2024 02:02:51 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ultimatedns.net header.s=mx99 header.b=ocdluXyt; spf=none (mx1.freebsd.org: domain of bsd-lists@bsdforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 42U22cF6038801 for ; Fri, 29 Mar 2024 19:02:44 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1711764164; x=1711764764; r=y; bh=XajQc5jgZGnjQTc3C3dpHo5beb/Ew21ULO3uNEp2GtI=; h=Date:From:To:Subject; b=ocdluXytXNBpW4xEVM7U0nALis/Xs93ikMR/41rBT3kJwy26+fwJ+wKL9mFUSI5cH bo3USPa2EYnJFiYf0otfsOKDlhOjavyScMw3UXtzM8JbDrl1tLzEVNnbiQXqNOji+d jA7HAcoh7tCDBeMC5KeyXCEWIpF1QLYWjPpaHwEaWhn4gAIN3xJE/HNTRXWHWz8pwQ 9nH28mdTJ+cp+bR3hyWQqMI324I7WWlPSgQpRdJnNu8b9FM8PSXfP5sJwH98i4uTvE hh4M3cNt9OZ13OWob3/KL6VB/ljsWv/5w5KmG7FI6Q353miAhFeH2jcmoaVdyzsur+ YmJNxqrwe1tjw== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://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, 29 Mar 2024 19:02:37 -0700 From: Chris To: freebsd-current Subject: Alt+Fn isn't functional. Has this been removed? User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.80 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_ALLOW(-0.20)[ultimatedns.net:s=mx99]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; local_wl_ip(0.00)[24.113.41.81]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[ultimatedns.net:+] X-Rspamd-Queue-Id: 4V60sl5lrwz4rSh I just poured the dist files onto an earlier 15 (after removing the earlier version). After booting into the new install, I no longer had any other tty's other than ttyv0. Alt+Fn has no affect, I'm only getting ttyv0. getty(8) is running, and a ps waux | grep getty shows they're all up. Only things I saved from the older install were the user/group databases, rc.conf,pf.conf,jail.conf, and wpa_supplicant.conf. What do I need to do to further isolate this problem? Thanks. System info: FreeBSD fbsd15 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC 2024 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU) IdeaPad 3 17IAU7 Id Refs Address Size Name 1 95 0xffffffff80200000 1d527c0 kernel 2 1 0xffffffff81f54000 287e8 fusefs.ko 3 1 0xffffffff82d8f000 1e3228 i915kms.ko 4 2 0xffffffff82f73000 85090 drm.ko 5 1 0xffffffff82ff9000 22b8 iic.ko 6 2 0xffffffff82ffc000 40e9 linuxkpi_video.ko 7 3 0xffffffff83001000 7358 dmabuf.ko 8 3 0xffffffff83009000 3378 lindebugfs.ko 9 1 0xffffffff8300d000 c338 ttm.ko 10 1 0xffffffff8301a000 5760 cuse.ko 11 1 0xffffffff83020000 3390 acpi_wmi.ko 12 1 0xffffffff83024000 4250 ichsmb.ko 13 1 0xffffffff83029000 2178 smbus.ko 14 1 0xffffffff8302c000 91260 if_iwlwifi.ko 15 1 0xffffffff830be000 5f90 ig4.ko 16 1 0xffffffff830c4000 4d20 ng_ubt.ko 17 3 0xffffffff830c9000 bbb8 netgraph.ko 18 2 0xffffffff830d5000 a250 ng_hci.ko 19 2 0xffffffff830e0000 2670 ng_bluetooth.ko 20 1 0xffffffff830e3000 3218 iichid.ko 21 5 0xffffffff830e7000 3380 hidbus.ko 22 1 0xffffffff830eb000 21e8 hms.ko 23 1 0xffffffff830ee000 40a8 hidmap.ko 24 1 0xffffffff830f3000 3355 hmt.ko 25 1 0xffffffff830f7000 22cc hconf.ko 26 1 0xffffffff830fa000 2260 pflog.ko 27 1 0xffffffff830fd000 56540 pf.ko 28 1 0xffffffff83154000 3560 fdescfs.ko From nobody Sat Mar 30 06:29: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 4V66ng3RwCz5GKcj for ; Sat, 30 Mar 2024 06:29:43 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V66nf59fRz4M2J for ; Sat, 30 Mar 2024 06:29:42 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ultimatedns.net header.s=mx99 header.b=k8E3R8i7; spf=none (mx1.freebsd.org: domain of bsd-lists@bsdforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 42U6TYLc027238; Fri, 29 Mar 2024 23:29:40 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1711780180; x=1711780780; r=y; bh=5z3w2pJcHdeotmqQQJ08iTsPODiejjo7cn+71zcbs1M=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=k8E3R8i7u3Z74FxyGDK8RLLVo9HHk+AGKRBq/cmOAcFDvCEAd99ONfittvBNbRX7S 8DqUppBZdv/MjibVwOJ3Yl2iv2OQKdiQG0nr50Bqys+fIm8kv2gbl89aztmqoS+tbg w5u3zHrdYhpCjumvIrS/8P+NzKXUZWjfhCDbRZllHJTwgNmVUfOotsP2S24wE2lTqQ F9+y0kLrByumQd9P89vLTSKevfilNMgDjZMBG6Ltlfl7YH7vbHmK2lwrIzGh3RdXcX PrxNwVxHyr5LxourS7jVHISyvySQ3VF/xiFcPfLQUStjydO1WKmQBxdSdl4/gSwu5g snlkrK8Up/d9A== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://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, 29 Mar 2024 23:29:34 -0700 From: Chris To: Michael Schuster Cc: freebsd-current Subject: Re: Alt+Fn isn't functional. Has this been removed? In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <6fdf112223b3737496803b2e44b3516a@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.80 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_ALLOW(-0.20)[ultimatedns.net:s=mx99]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[ultimatedns.net:+] X-Rspamd-Queue-Id: 4V66nf59fRz4M2J On 2024-03-29 23:06, Michael Schuster wrote: > Two ideas: > - does CTL-ALT-Fn work? Thanks. But no, I tried that. > - perhaps the number of predefined ttys was overwritten/set to 0 somewhere? I'm only aware of /etc/ttys, and they're all available (uncommented) and ps(1) indicates getty(8) is running on all the normally assigned ttyv(n)'s. Thanks for the reply! --Chris > > HTH > Michael > > On Sat, Mar 30, 2024, 03:03 Chris wrote: > >> I just poured the dist files onto an earlier 15 (after removing >> the earlier version). After booting into the new install, I no longer >> had any other tty's other than ttyv0. Alt+Fn has no affect, I'm only >> getting ttyv0. getty(8) is running, and a ps waux | grep getty shows >> they're all up. Only things I saved from the older install were the >> user/group databases, rc.conf,pf.conf,jail.conf, and wpa_supplicant.conf. >> >> What do I need to do to further isolate this problem? >> >> Thanks. >> >> System info: >> >> FreeBSD fbsd15 15.0-CURRENT FreeBSD 15.0-CURRENT #0 >> main-n268793-220ee18f1964: >> Thu Mar 14 02:58:39 UTC 2024 >> root@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >> amd64 >> >> CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU) >> >> IdeaPad 3 17IAU7 >> >> Id Refs Address Size Name >> 1 95 0xffffffff80200000 1d527c0 kernel >> 2 1 0xffffffff81f54000 287e8 fusefs.ko >> 3 1 0xffffffff82d8f000 1e3228 i915kms.ko >> 4 2 0xffffffff82f73000 85090 drm.ko >> 5 1 0xffffffff82ff9000 22b8 iic.ko >> 6 2 0xffffffff82ffc000 40e9 linuxkpi_video.ko >> 7 3 0xffffffff83001000 7358 dmabuf.ko >> 8 3 0xffffffff83009000 3378 lindebugfs.ko >> 9 1 0xffffffff8300d000 c338 ttm.ko >> 10 1 0xffffffff8301a000 5760 cuse.ko >> 11 1 0xffffffff83020000 3390 acpi_wmi.ko >> 12 1 0xffffffff83024000 4250 ichsmb.ko >> 13 1 0xffffffff83029000 2178 smbus.ko >> 14 1 0xffffffff8302c000 91260 if_iwlwifi.ko >> 15 1 0xffffffff830be000 5f90 ig4.ko >> 16 1 0xffffffff830c4000 4d20 ng_ubt.ko >> 17 3 0xffffffff830c9000 bbb8 netgraph.ko >> 18 2 0xffffffff830d5000 a250 ng_hci.ko >> 19 2 0xffffffff830e0000 2670 ng_bluetooth.ko >> 20 1 0xffffffff830e3000 3218 iichid.ko >> 21 5 0xffffffff830e7000 3380 hidbus.ko >> 22 1 0xffffffff830eb000 21e8 hms.ko >> 23 1 0xffffffff830ee000 40a8 hidmap.ko >> 24 1 0xffffffff830f3000 3355 hmt.ko >> 25 1 0xffffffff830f7000 22cc hconf.ko >> 26 1 0xffffffff830fa000 2260 pflog.ko >> 27 1 0xffffffff830fd000 56540 pf.ko >> 28 1 0xffffffff83154000 3560 fdescfs.ko >> >> From nobody Sat Mar 30 06:37:01 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 4V66yJ647Jz5GLV7 for ; Sat, 30 Mar 2024 06:37:12 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V66yJ1dkZz4NNf for ; Sat, 30 Mar 2024 06:37:12 +0000 (UTC) (envelope-from freebsd@grem.de) Authentication-Results: mx1.freebsd.org; none Received: by mail.evolve.de (OpenSMTPD) with ESMTP id e55af702; Sat, 30 Mar 2024 06:37:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=20180501; bh=YIoY2NGCOF+bhI pq5LjRj2OA8Fw=; b=Gar7e3xHjZqf2LEq/Qe9J2CldgC997GuoxFZR9SjmIQcPS IHKRsITSG1Jx3uzXHu6dpPbOtayBGHyO/yNnliPr2zd6lyLKAIQTGaqGFMPClgFP AqPR0gHCTJ1Z/tkNfWdW/EcLaxBZ8IFF8Y37cBYpHXodqTL1r+B2Pw7+welYKGRt cEMU2jNM0Qmk5WkYjRTYRM7SSkyk4p0oA8SjR1TOiygGNw3xA9bZuI9RLx9Fo4ja nW4VLglQPBcvn/r7IySgHr29WEysLG9rvKs95bKM6S9cIDZCTwFPeL2wxHjDpTjp jCFzb+0p9ikvoBfCtOFZwfYK0Bixwoc1aRaJX45w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; q=dns; s=20180501; b=hjQTAv89 MkRx8IyUS3iij3/1T6xDp4T+Z3/edj7NYeEIaSAv55tq0EL/2V9BLmmuuxa8q4+7 XP6SVBnwlpfVVDnycbn3pe5uUumUE/4TRQLBRnTjAIW2AdBkpLOvi+j+f5/psZbZ W5c+cwk0iyMcL+u770wOHhLlgnuR3Vdcyg2YMLxqEVX+U5rV1LOiuXlPHSLCWEc9 Mx8qE3FDO97QbVPfAkdAPyLtpbN4ggJnW2hv8kR6HLIh2q69fvpGkLXesmHyTa3R sQ5b5z0pSbWaLUOgVDmYKzfvL79W6dW4t9oYwcO9SCSYxCyrNgMAWtWRzaVGOxVu r6xi+DnqKJI/0g== Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id b8b574a6 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 30 Mar 2024 06:37:03 +0000 (UTC) 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 (1.0) Subject: Re: Alt+Fn isn't functional. Has this been removed? From: Michael Gmelin In-Reply-To: <6fdf112223b3737496803b2e44b3516a@bsdforge.com> Date: Sat, 30 Mar 2024 07:37:01 +0100 Cc: Michael Schuster , freebsd-current Message-Id: <4799B276-B42B-404B-AAAE-B26F1C12DAD0@grem.de> References: <6fdf112223b3737496803b2e44b3516a@bsdforge.com> To: Chris X-Mailer: iPhone Mail (20H330) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE] X-Rspamd-Queue-Id: 4V66yJ1dkZz4NNf > On 30. Mar 2024, at 07:30, Chris wrote: >=20 > =EF=BB=BFOn 2024-03-29 23:06, Michael Schuster wrote: >> Two ideas: >> - does CTL-ALT-Fn work? > Thanks. But no, I tried that. >=20 >> - perhaps the number of predefined ttys was overwritten/set to 0 somewher= e? > I'm only aware of /etc/ttys, and they're all available (uncommented) and > ps(1) indicates getty(8) is running on all the normally assigned ttyv(n)'s= . >=20 > Thanks for the reply! >=20 > --Chris In case you have a keymap defined on rc.conf, try commenting that out, reboo= t amd see if it makes a difference (as a debugging measure).=20 Cheers Michael >> HTH >> Michael >>> On Sat, Mar 30, 2024, 03:03 Chris wrote: >>> I just poured the dist files onto an earlier 15 (after removing >>> the earlier version). After booting into the new install, I no longer >>> had any other tty's other than ttyv0. Alt+Fn has no affect, I'm only >>> getting ttyv0. getty(8) is running, and a ps waux | grep getty shows >>> they're all up. Only things I saved from the older install were the >>> user/group databases, rc.conf,pf.conf,jail.conf, and wpa_supplicant.conf= . >>> What do I need to do to further isolate this problem? >>> Thanks. >>> System info: >>> FreeBSD fbsd15 15.0-CURRENT FreeBSD 15.0-CURRENT #0 >>> main-n268793-220ee18f1964: >>> Thu Mar 14 02:58:39 UTC 2024 >>> root@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >>> amd64 >>> CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU) >>> IdeaPad 3 17IAU7 >>> Id Refs Address Size Name >>> 1 95 0xffffffff80200000 1d527c0 kernel >>> 2 1 0xffffffff81f54000 287e8 fusefs.ko >>> 3 1 0xffffffff82d8f000 1e3228 i915kms.ko >>> 4 2 0xffffffff82f73000 85090 drm.ko >>> 5 1 0xffffffff82ff9000 22b8 iic.ko >>> 6 2 0xffffffff82ffc000 40e9 linuxkpi_video.ko >>> 7 3 0xffffffff83001000 7358 dmabuf.ko >>> 8 3 0xffffffff83009000 3378 lindebugfs.ko >>> 9 1 0xffffffff8300d000 c338 ttm.ko >>> 10 1 0xffffffff8301a000 5760 cuse.ko >>> 11 1 0xffffffff83020000 3390 acpi_wmi.ko >>> 12 1 0xffffffff83024000 4250 ichsmb.ko >>> 13 1 0xffffffff83029000 2178 smbus.ko >>> 14 1 0xffffffff8302c000 91260 if_iwlwifi.ko >>> 15 1 0xffffffff830be000 5f90 ig4.ko >>> 16 1 0xffffffff830c4000 4d20 ng_ubt.ko >>> 17 3 0xffffffff830c9000 bbb8 netgraph.ko >>> 18 2 0xffffffff830d5000 a250 ng_hci.ko >>> 19 2 0xffffffff830e0000 2670 ng_bluetooth.ko >>> 20 1 0xffffffff830e3000 3218 iichid.ko >>> 21 5 0xffffffff830e7000 3380 hidbus.ko >>> 22 1 0xffffffff830eb000 21e8 hms.ko >>> 23 1 0xffffffff830ee000 40a8 hidmap.ko >>> 24 1 0xffffffff830f3000 3355 hmt.ko >>> 25 1 0xffffffff830f7000 22cc hconf.ko >>> 26 1 0xffffffff830fa000 2260 pflog.ko >>> 27 1 0xffffffff830fd000 56540 pf.ko >>> 28 1 0xffffffff83154000 3560 fdescfs.ko >=20 From nobody Sat Mar 30 08:02:28 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 4V68rx2Fczz5GVF0 for ; Sat, 30 Mar 2024 08:02:41 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4V68rr6R86z4V37 for ; Sat, 30 Mar 2024 08:02:35 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 42U82SO7007153 for ; Sat, 30 Mar 2024 17:02:28 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 30 Mar 2024 17:02:28 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: Alt+Fn isn't functional. Has this been removed? Message-Id: <20240330170228.c31e0e4366194e5d4ea25efa@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: - X-Spamd-Result: default: False [-1.33 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.89)[-0.889]; NEURAL_HAM_LONG(-0.75)[-0.748]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:153.125.133.16/28]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; HAS_ORG_HEADER(0.00)[]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[sakura.ne.jp]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4V68rr6R86z4V37 On Fri, 29 Mar 2024 19:02:37 -0700 Chris wrote: > I just poured the dist files onto an earlier 15 (after removing > the earlier version). After booting into the new install, I no longer > had any other tty's other than ttyv0. Alt+Fn has no affect, I'm only > getting ttyv0. getty(8) is running, and a ps waux | grep getty shows > they're all up. Only things I saved from the older install were the > user/group databases, rc.conf,pf.conf,jail.conf, and wpa_supplicant.conf. > > What do I need to do to further isolate this problem? > > Thanks. > > System info: > > FreeBSD fbsd15 15.0-CURRENT FreeBSD 15.0-CURRENT #0 > main-n268793-220ee18f1964: > Thu Mar 14 02:58:39 UTC 2024 > root@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU) > > IdeaPad 3 17IAU7 > > Id Refs Address Size Name > 1 95 0xffffffff80200000 1d527c0 kernel > 2 1 0xffffffff81f54000 287e8 fusefs.ko > 3 1 0xffffffff82d8f000 1e3228 i915kms.ko > 4 2 0xffffffff82f73000 85090 drm.ko > 5 1 0xffffffff82ff9000 22b8 iic.ko > 6 2 0xffffffff82ffc000 40e9 linuxkpi_video.ko > 7 3 0xffffffff83001000 7358 dmabuf.ko > 8 3 0xffffffff83009000 3378 lindebugfs.ko > 9 1 0xffffffff8300d000 c338 ttm.ko > 10 1 0xffffffff8301a000 5760 cuse.ko > 11 1 0xffffffff83020000 3390 acpi_wmi.ko > 12 1 0xffffffff83024000 4250 ichsmb.ko > 13 1 0xffffffff83029000 2178 smbus.ko > 14 1 0xffffffff8302c000 91260 if_iwlwifi.ko > 15 1 0xffffffff830be000 5f90 ig4.ko > 16 1 0xffffffff830c4000 4d20 ng_ubt.ko > 17 3 0xffffffff830c9000 bbb8 netgraph.ko > 18 2 0xffffffff830d5000 a250 ng_hci.ko > 19 2 0xffffffff830e0000 2670 ng_bluetooth.ko > 20 1 0xffffffff830e3000 3218 iichid.ko > 21 5 0xffffffff830e7000 3380 hidbus.ko > 22 1 0xffffffff830eb000 21e8 hms.ko > 23 1 0xffffffff830ee000 40a8 hidmap.ko > 24 1 0xffffffff830f3000 3355 hmt.ko > 25 1 0xffffffff830f7000 22cc hconf.ko > 26 1 0xffffffff830fa000 2260 pflog.ko > 27 1 0xffffffff830fd000 56540 pf.ko > 28 1 0xffffffff83154000 3560 fdescfs.ko Are you sure your function keys are actually function keys? Not sure your IdeaPad is, but some Lenovo notebooks are configured function keys as special (mute, radio,...) keys by default and needs to configure in UEFI firmware to switch to function keys. If it's the case, Fn+Alt+F2 would switch to vty1. -- Tomoaki AOKI From nobody Sat Mar 30 13:40: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 4V6JMG6rknz5Fdr1 for ; Sat, 30 Mar 2024 13:40:58 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4V6JMG16gPz43gq for ; Sat, 30 Mar 2024 13:40:57 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de Received: from [62.216.203.147] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1rqYx5-0038Xt-Cb; Sat, 30 Mar 2024 14:40:55 +0100 Received: from localhost.my.domain (c720-1400094 [127.0.0.1]) by localhost.unixarea.de (8.17.1/8.14.9) with ESMTP id 42UDeslj003860; Sat, 30 Mar 2024 14:40:54 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.17.1/8.14.9/Submit) id 42UDesBo003859; Sat, 30 Mar 2024 14:40:54 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 30 Mar 2024 14:40:54 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org, Michael Gmelin Subject: Re: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org, Michael Gmelin References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 14.0-CURRENT r1400094 (amd64) X-message-flag: Mails in HTML will not be read! Please, only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 62.216.203.147 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.898]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[unixarea.de]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; MISSING_XM_UA(0.00)[]; HAS_XAW(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[guru@unixarea.de]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_XOIP(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4V6JMG16gPz43gq (For the not working Wifi chip, I use at the moment an USB-Wifi dongle, Realtek RTL8191S WLAN Adapter, which works fine). I also can't get Xorg plus twm up; it says in /var/log/Xorg.0.log at the end: ... REDWOOD, ATI Mobility Radeon Graphics, CEDAR, ATI FirePro 2270, ATI Radeon HD 5450, CAYMAN, AMD Radeon HD 6900 Series, AMD Radeon HD 6900M Series, Mobility Radeon HD 6000 Series, BARTS, AMD Radeon HD 6800 Series, AMD Radeon HD 6700 Series, TURKS, CAICOS, ARUBA, TAHITI, PITCAIRN, VERDE, OLAND, HAINAN, BONAIRE, KABINI, MULLINS, KAVERI, HAWAII [ 248.442] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 248.442] (II) scfb: driver for wsdisplay framebuffer: scfb [ 248.442] (II) VESA: driver for VESA chipsets: vesa [ 248.442] (--) Using syscons driver with X support (version 2.0) [ 248.442] (--) using VT number 9 [ 248.447] (EE) open /dev/dri/card0: No such file or directory [ 248.447] (WW) Falling back to old probe method for modesetting [ 248.447] (EE) open /dev/dri/card0: No such file or directory [ 248.447] (WW) Falling back to old probe method for scfb [ 248.447] scfb trace: probe start ... The kernel modules loaded are: Id Refs Address Size Name 1 139 0xffffffff80200000 1d4f010 kernel 2 1 0xffffffff81f50000 36c0 coretemp.ko 3 1 0xffffffff81f55000 9c48 if_cdce.ko 4 2 0xffffffff81f5f000 6138 uether.ko 5 1 0xffffffff81f66000 a698 cuse.ko 6 1 0xffffffff81f71000 f7f38 ipl.ko 7 1 0xffffffff83c00000 462be0 zfs.ko 8 1 0xffffffff84063000 1510b8 radeonkms.ko 9 2 0xffffffff841b5000 73da0 drm.ko 10 1 0xffffffff83bd7000 22a8 iic.ko 11 3 0xffffffff83bda000 1100 linuxkpi_gplv2.ko 12 4 0xffffffff83bdc000 6320 dmabuf.ko 13 4 0xffffffff83be3000 3080 linuxkpi_hdmi.ko 14 1 0xffffffff83be7000 c7b0 ttm.ko 15 1 0xffffffff83bf4000 3370 acpi_wmi.ko 16 1 0xffffffff83bf8000 5ee0 ig4.ko 17 1 0xffffffff84229000 3210 intpm.ko 18 1 0xffffffff8422d000 2178 smbus.ko 19 1 0xffffffff84230000 30ad8 linux.ko 20 4 0xffffffff84261000 be30 linux_common.ko 21 1 0xffffffff8426d000 2ccf8 linux64.ko 22 1 0xffffffff8429a000 2270 pty.ko 23 1 0xffffffff8429d000 3540 fdescfs.ko 24 1 0xffffffff842a1000 73c0 linprocfs.ko 25 1 0xffffffff842a9000 43e4 linsysfs.ko 26 1 0xffffffff842ae000 4d00 ng_ubt.ko 27 6 0xffffffff842b3000 bb28 netgraph.ko 28 2 0xffffffff842bf000 a238 ng_hci.ko 29 4 0xffffffff842ca000 2668 ng_bluetooth.ko 30 1 0xffffffff842cd000 a7e0 if_rsu.ko 31 1 0xffffffff842d8000 3218 iichid.ko 32 5 0xffffffff842dc000 32a8 hidbus.ko 33 1 0xffffffff842e0000 f250 ng_l2cap.ko 34 1 0xffffffff842f0000 19f08 ng_btsocket.ko 35 1 0xffffffff8430a000 38b8 ng_socket.ko 37 1 0xffffffff8432e000 21e0 hms.ko 38 1 0xffffffff84331000 40a8 hidmap.ko 39 1 0xffffffff84336000 334d hmt.ko 40 1 0xffffffff8433a000 22c4 hconf.ko The complete Xorg.0.log is here: http://www.unixarea.de/Xorg.0.log.txt Thanks in advance for ideas. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sat Mar 30 19:44:56 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 4V6SRJ2S8gz5Fqgq; Sat, 30 Mar 2024 19:45:00 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from thyme.eden.le-Fay.ORG (THYME.EDEN.LE-FAY.ORG [81.187.47.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4V6SRH2NJgz4ffD; Sat, 30 Mar 2024 19:44:59 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=le-fay.org header.s=thyme header.b=kIcSU69y; dmarc=none; spf=pass (mx1.freebsd.org: domain of lexi@le-fay.org designates 81.187.47.194 as permitted sender) smtp.mailfrom=lexi@le-fay.org Received: from iris.eden.le-Fay.ORG (IRIS.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:106:3::6]) by thyme.eden.le-Fay.ORG (Postfix) with ESMTP id D47C462; Sat, 30 Mar 2024 19:44:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=thyme; t=1711827895; bh=0NMhb151AW3vQmmm3D7/kUOEeOLpPbbN8IGcazNhee0=; h=Date:From:To:Subject; b=kIcSU69yY13zgpOFyqEQtqR7JwCpCfkq4gIgck2FSZlQBaZBOv6NHt4OHiYlHcN0D bWs8G1wlNBzKOzRMwwWQzhV/pxBVlPN5mtz/h/uqMJiFiHAPT/EAvGUiUsT8CY5Yjz eyr3gmiVX6/WHehhuA0qDrgOZGrsa6Dv2/WnoAv0= Received: from ilythia.eden.le-fay.org (ILYTHIA.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:106:3::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 45D672C0400; Sat, 30 Mar 2024 19:44:56 +0000 (GMT) Date: Sat, 30 Mar 2024 19:44:56 +0000 From: Lexi Winter To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: 15.0 on RPi4, USB broken: uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oABTNl0330h8Ghq1" Content-Disposition: inline X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.48 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.981]; R_DKIM_ALLOW(-0.20)[le-fay.org:s=thyme]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:81.187.47.194]; RCVD_NO_TLS_LAST(0.10)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[le-fay.org:dkim]; ASN(0.00)[asn:20712, ipnet:81.187.0.0/16, country:GB]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[81.187.47.194:from]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[le-fay.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[le-fay.org:+] X-Rspamd-Queue-Id: 4V6SRH2NJgz4ffD --oABTNl0330h8Ghq1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hello, i'm using 15.0 (f66a994d59) on an 4GB RPi4 with a USB<>SATA adapter for the root disk: usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA (0x174c:0x55aa) ugen0.3: at usbus0 umass0 on uhub1 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:1:0: Attached to scbus1 da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number 123456789019 da0: 40.000MB/s transfers da0: 228936MB (468862128 512 byte sectors) da0: quirks=0x2 when connected via USB 2, this works fine. when connected via USB 3.0, the device sometimes fails to attach on boot, causing mountroot to fail. i can reproduce this reliably with both GENERIC-NODEBUG and a custom modular kernel, and sometimes (but not every boot) with GENERIC. when the problem happens, with USB_DEBUG enabled, the kernel logs: uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2 however, if i boot with "boot -v", the device is reliably detected correctly. since -v shouldn't cause any functional changes, i suspect this may be some kind of timing issue. i've tried increasing some of the USB timings (hw.usb.timings.*) but this didn't seem to have any effect. is there anything else i could try that might affect this, or is this perhaps a known issue? thanks, lexi. --oABTNl0330h8Ghq1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmYIa7UACgkQDHqbqZ41 x5kEGAv+MCRnOpETwBz+xypibx/Odjkl52TO03q7A2tsqE/l/WZZ3OPvS+uq28x8 tTdE4VdZ87rbHaoLMZEJS09CGokjDcHhAXWKhac2G84F5NgI7/3Lu1P9XKihUfTx E2m9K5hYuRQIqFlF/4+RgJv0ejTVSCO6QKfqwcXvEVPqTu601x6u3HKFWlqwktMr wjpvgiKNJy6t1XRPcyCKb1ZRFSq+FJugBe839Vfmw1iNHEW+JkCtQE0PHP0a/uii VlRrmDO92gYQAadUB2O1k2uC1eN5z36bojUjmLFW+YuwotmPN6YEIvy53ZfU//jQ 4BEV/HCRWHd8UkZlLFpNaieyaxEzeG3g9nTWqt64gjuWNSY4obl3X6vULcO++iRi HuKI0eVIG/lHc0yEOe1Cu3ZcNq150XqL5OCmioBWsMlJXOGw2xrcdIP0GfAIwM44 Tef6vCag0BuLPrDtJW6SU7yxPoGhUfKV9CQO2esfZDWGIxZqA0k6EoLMPNp+KQUy 5/NYfO+q =W2Aw -----END PGP SIGNATURE----- --oABTNl0330h8Ghq1-- From nobody Sun Mar 31 14:31:43 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 4V6xS6167Fz5G8vb for ; Sun, 31 Mar 2024 14:32:22 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V6xS46dp8z4dG9; Sun, 31 Mar 2024 14:32:20 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b="Rn/2TWYk"; dmarc=pass (policy=quarantine) header.from=leidinger.net; 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 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://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=1711895521; 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=z6wIK1zzHR1IyzTEGC774D23BtMnnx38nJ9P1YF0tuI=; b=Rn/2TWYkNIIUwqs6c4B7RZDLRiAydTY57AjGdgMbWnXm07F81INAXjB04fnNOJlFINb33N wrdwuKf2TqjRGt1sw36dwmHSWOQBi+JoF9aO4Ug0McJEGCWjHmPwCUMKaE/lkJeXGCoJeI tGpaF7J9+taATXqJSu/qp+UJBZVg3un7OlB5Uls8tUy4Q2mok452yYrofksXZ6wHDV7tq6 vJrjl0pyNJA7NUKh9PrIKXf4lVSjU36YGN81oObzha0nLGba7H7Q7YhGeJMlk+fJJ6nwgG 4clVQnPhdEB+Bts+9eLhE28lf36z8sDD39Hn8rIBPx0sAaHMX1rOg324fRZz/g== Date: Sun, 31 Mar 2024 16:31:43 +0200 From: Alexander Leidinger To: Alexander Leidinger Cc: Mark Johnston , Current , bnovkov@freebsd.org Subject: Re: Multiple issues with current (kldload failures, missing CTF stuff, pty issues, ...) In-Reply-To: References: <09ef22679b76cb2dbeace8e78bf9f80e@Leidinger.net> Message-ID: <888637ab03455a459342ba611c09b627@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_c5498fd2cfe61cab96a94b8b1455a9d5"; micalg=pgp-sha256 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.06 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.960]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4V6xS46dp8z4dG9 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_c5498fd2cfe61cab96a94b8b1455a9d5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-03-29 18:21, schrieb Alexander Leidinger: > Am 2024-03-29 18:13, schrieb Mark Johnston: >> On Fri, Mar 29, 2024 at 04:52:55PM +0100, Alexander Leidinger wrote: >>> Hi, >>> >>> sources from 2024-03-11 work. Sources from 2024-03-25 and today don't >>> work >>> (see below for the issue). As the monthly stabilisation pass didn't >>> find >>> obvious issues, it is something related to my setup: >>> - not a generic kernel >>> - very modular kernel (as much as possible as a module) >>> - bind_now (a build without fails too, tested with clean /usr/obj) >>> - ccache (a build without fails too, tested with clean /usr/obj) >>> - kernel retpoline (build without in progress) >>> - userland retpoline (build without in progress) >>> - kernel build with WITH_CTF / DDB_CTF (next one to test if it isn't >>> retpoline) >>> - -fno-builtin >>> - CPUFLAGS=native (except for stuff in /usr/src/sys/boot) >>> - malloc production >>> - COPTFLAGS= -O2 -pipe >>> >>> The issue is, that kernel modules load OK from loader, but once it >>> starts >>> init any module fails to load (e.g. via autodetection of hardware or >>> rc.conf >>> kld_list) with the message that the kernel and module versions are >>> out of >>> sync and the module refuses to load. >> >> What is the exact revision you're running? There were some unrelated >> changes to the kernel linker around the same time. > > The working src is from 2024-03-11-094351 (GMT+0100). > The failing src was fetched after Glebs stabilization week message (and > todays src before the sound stuff still fails). > > Retpoline wasn't the cause, next test is the CTF stuff in the kernel... A rather obscure problem was causing this. The "last" BE had canmount set to "on" instead of "noauto". No idea how this happened, but this resulted in the "last" BE to be mounted on "zfs mount -a" on top of the current BE. This means that all modules loaded after the zfs rc script has run was loading old kernel modules and the error message of kernel version mismatch was correct. I fiund the issue while bisecting the tree and suddenly the error message went away but the new issue of missing dev entries popped up (/dev was mounted correctly on the booting dataset, but the last BE was mounted on top of it and /dev went empty...). It looks to me like bectl was doing this (from "zpool history")... 2024-03-11.14:16:31 zpool set bootfs=rpool/ROOT/2024-03-11-094351 rpool 2024-03-11.14:16:31 zfs set canmount=noauto rpool/ROOT/2024-01-18-092730 2024-03-11.14:16:31 zfs set canmount=noauto rpool/ROOT/2024-02-10-144617 2024-03-11.14:16:32 zfs set canmount=noauto rpool/ROOT/2024-02-11-212006 2024-03-11.14:16:32 zfs set canmount=noauto rpool/ROOT/2024-02-16-082836 2024-03-11.14:16:32 zfs set canmount=noauto rpool/ROOT/2024-02-24-140211 2024-03-11.14:16:32 zfs set canmount=noauto rpool/ROOT/2024-02-24-140211_ok 2024-03-11.14:16:33 zfs set canmount=on rpool/ROOT/2024-03-11-094351 2024-03-11.14:16:33 zfs promote rpool/ROOT/2024-03-11-094351 2024-03-11.14:17:03 zfs destroy -r rpool/ROOT/2024-02-24-140211_ok I surely didn't do the "zfs set canmount=..." for those by hand. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_c5498fd2cfe61cab96a94b8b1455a9d5 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmYJc9wACgkQEg2wmwP4 2IZdmw/8CWcO//WcKt5rf77I6y5H8Rv7XA42z0cBott1qx2YoPRHTlhox7iIeCPb YWkz81b7asLceCjh5T2GWwDmIVObyiiXsdfr2YHD+kvDxUzSRRGSk+37phcEU9Zs 8o3tt3KYscG8lY6fyn/icMmkTgc+jqYWvhMxKVf3JlyDgrUkER+z4AcOER7hFBOg DIKkOuzaFzgEuscIqVNgUtVdkRDcKixSGOd3XFO+mhrZ8hjb4O5PsMpJlqVXXu9J f54IG5PwBW1qx5NcLwAYWKw08Y40Mo3CDJHJu/LXFbOu5wXY3S03+sRyq3h5a1d2 HvW7iV+HN9uTdAjZvEYchAvT4t5Yug46Cz1+BGcHm3tRKSSMZKnsfzIAN8GtWuLd kBcBnPAQKeJGzAMd/kwWZ47gQgIc53nQeSuvgwYaMSMm6nwRZEjA7b67XLwzle2J uYOl7aKzBzFZp+5hozBvsu2XGhuUIIEMp2zBGqgUZKStL3SM2cd9FENLI7Lsd77G P/Iq/f0WToYADSJtyNhmbul5VVZYWxGzOC5C3Q5S7rCsh2Zzky6avXX0ZUOQ2pkC K8ZVijeNJVX+kPsQTE6VdkTzsN/n6sIkVNw44JMfP3QqSSGvkxYLVRojnfd6OgPw AJ7HDzRIWJqFNRqQouCpaTqhzaL1bGwfm6gaCMU1IiEEEMaPQ10= =O/PC -----END PGP SIGNATURE----- --=_c5498fd2cfe61cab96a94b8b1455a9d5-- From nobody Sun Mar 31 18:59:51 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 4V73Nz2pfZz5GC9F; Sun, 31 Mar 2024 19:00:03 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V73Ny67rPz4L4T; Sun, 31 Mar 2024 19:00:02 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711911602; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WfenXLC3Ck0RRpfHpuomPDkkqtaTFUmsI2noN6ZpDSM=; b=i14zxMVnUWOI9pCcPvNTwo8GeKZNq7TdKFxh8GC7vO/ejNY42jBRCsRhFQ/74EAUt+HcIC QQJojQxdYvdkoWB6EpG5JI7ZFYaxEn/QhHV93OaC/9Z1hPOA5+zuo7Eg7bGCUr4ck/WO9J +LBxVGF8c4hAIJZXwjvJwPRkzOVL7nSitSmfV7IsiYX+CmJisaFWKXLgV5fPIyVBlvKqt6 vLXlSrOiQwpK3Sup1F1ZbIPjRx9dmtdYeWCaq4CVeg+fUGalsl2onQZxUfzzSiKDGhCodX iM0JxS1NB+4ih4/UHWFlH+ay1qMuUgXkRyAXopG9pHfCgCVE0Jw1jWWyfCWarw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711911602; a=rsa-sha256; cv=none; b=QA/0SviDs/bCTJH0QHak14/8FSldBBIrk8bwAeK7Zz5O4oHOJh4ttYQdd78RCrsfcRJKXD KKzRbEKoJhIy4YIsSOkCoeU6vNqwQIWJ3XpeLs2IPeK1PZq8Z36Hu6rN6mOaipzjlY5ge3 3yTGm1BDOJ/j0FGy6fBqMJtSOlN4AF67qkQORxke9wdd2HF8LMbbMXWvNuyZxjIxScehtm 3N51ZkXgainqDksn2ZmWusR5FqTfjXNTe53SrhoRvZEzH5HSTZhcd56wdeb9e9lL/gzTBR w3J6Q0jlRFdOWpP6VP6jxDCua4aBfmJezNkAvOSJIALc8mJGVwsz4Vzj45uf2w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711911602; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WfenXLC3Ck0RRpfHpuomPDkkqtaTFUmsI2noN6ZpDSM=; b=pdzNzKi6HLxPeJcVbvRhU12k+Kqu738g14lxzdnK1VCkkdqx+PNZmO4yps0536aeHSJ/XR HZDJg++dghukCN3FwLyGADJvJJrXgVzJaDJ4Z0ka8XGkJCaxIDwXqTyMS4o0PRCN2lJdo0 RS7yAX4htHohYUwEITSlXjDySddnPH7FqTgO+l3XDXjq2RkhssQfVkmyNVEzah7Uk427b4 G3X7xa4GyXtB7bfquSIkrlx6f1mam1B3JpA6snNbkIfQDw6vKhtB4bwwUCN4GWZzHGFOkr Hb8Y84th91BWmCkIoPNILWGFi5vbiGyskKsY8DJCZGSoc24HvLc31uTW54S8OA== Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4V73Ny5dNJzY8h; Sun, 31 Mar 2024 19:00:02 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-430ca04b09bso24348881cf.1; Sun, 31 Mar 2024 12:00:02 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVzH4LN+vGzHU5sqwgsRZRbtuIZqDh0tmEG/cEkSV6MR566sHm5uM6/fHRLlGe/4xCON3pDEYE/btNLPECy5M9KTQaDdRGxWFokso0= X-Gm-Message-State: AOJu0YyFTFX7OvbWxM/fCtRPwn3xsoMUXl8+czJoQplFFQjtA/D9TfT7 JJh7JVx3uDRU6ug7iC34QaVyVmwG1GUo9VH9h9FbC0iSaiO+hIpC116L7uJZ7dVcgBFtCLQhO1X z7red8X1Je3cJMtcPqcPUxFAvK1M= X-Google-Smtp-Source: AGHT+IEGtjv1rUx62zpzKErNeaFnIw2Yf9P2MfW0zkK1IkgT0L5sZcGytrQastKaUyl7lAFTK4ijlxVT7tgz6GlUYCc= X-Received: by 2002:a05:622a:24c:b0:431:33ec:be08 with SMTP id c12-20020a05622a024c00b0043133ecbe08mr10905187qtx.15.1711911602011; Sun, 31 Mar 2024 12:00:02 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Nuno Teixeira Date: Sun, 31 Mar 2024 19:59:51 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: 15.0 on RPi4, USB broken: uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000ecd0160614f97a11" --000000000000ecd0160614f97a11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, If you got a fan in your rpi4 box, you could try to overclock it. If not, there is a funcionality in config.txt to overclock it just for a few seconds at boot time. I can't remember the funtion but I'm looking at: https://www.raspberrypi.com/documentation/computers/config_txt.html Cheers, Lexi Winter escreveu (s=C3=A1bado, 30/03/2024 =C3=A0(s) 1= 9:45): > hello, > > i'm using 15.0 (f66a994d59) on an 4GB RPi4 with a USB<>SATA adapter for > the root disk: > > usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device > ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA (0x174c:0x55aa) > ugen0.3: at usbus0 > umass0 on uhub1 > umass0: 2.10/1.00, addr 2> on usbus0 > umass0: SCSI over Bulk-Only; quirks =3D 0x0100 > umass0:1:0: Attached to scbus1 > da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number 123456789019 > da0: 40.000MB/s transfers > da0: 228936MB (468862128 512 byte sectors) > da0: quirks=3D0x2 > > when connected via USB 2, this works fine. when connected via USB 3.0, > the device sometimes fails to attach on boot, causing mountroot to fail. > i can reproduce this reliably with both GENERIC-NODEBUG and a custom > modular kernel, and sometimes (but not every boot) with GENERIC. > > when the problem happens, with USB_DEBUG enabled, the kernel logs: > > uhub_reattach_port: port 2 reset failed, error=3DUSB_ERR_TIMEOUT > uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2 > > however, if i boot with "boot -v", the device is reliably detected > correctly. since -v shouldn't cause any functional changes, i suspect > this may be some kind of timing issue. > > i've tried increasing some of the USB timings (hw.usb.timings.*) but > this didn't seem to have any effect. is there anything else i could try > that might affect this, or is this perhaps a known issue? > > thanks, lexi. > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000ecd0160614f97a11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

If you got a fan in y= our rpi4 box, you could try to overclock it.
If not, there is= a funcionality in config.txt to overclock it just for a few seconds at boo= t time.

I can't remember the funtion but I'm look= ing at:
https://www.raspberrypi.com/documentation/computers/config_= txt.html

Cheers,

Lexi Winter <lexi@le-fay.org> escreveu (s=C3=A1bado, 30/0= 3/2024 =C3=A0(s) 19:45):
hello,

i'm using 15.0 (f66a994d59) on an 4GB RPi4 with a USB<>SATA adapt= er for
the root disk:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device ASM= 1153USB3.0TOSATA ASM1153USB3.0TOSATA (0x174c:0x55aa)
ugen0.3: <ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA> at usbus0
umass0 on uhub1
umass0: <ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA, class 0/0, rev 2.10/1.= 00, addr 2> on usbus0
umass0:=C2=A0 SCSI over Bulk-Only; quirks =3D 0x0100
umass0:1:0: Attached to scbus1
da0 at umass-sim0 bus 0 scbus1 target 0 lun 0
da0: <ASM1153U ASM1153USB3.0TOS 0> Fixed Direct Access SPC-4 SCSI dev= ice
da0: Serial Number 123456789019
da0: 40.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2<NO_6_BYTE>

when connected via USB 2, this works fine.=C2=A0 when connected via USB 3.0= ,
the device sometimes fails to attach on boot, causing mountroot to fail. i can reproduce this reliably with both GENERIC-NODEBUG and a custom
modular kernel, and sometimes (but not every boot) with GENERIC.

when the problem happens, with USB_DEBUG enabled, the kernel logs:

uhub_reattach_port: port 2 reset failed, error=3DUSB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2

however, if i boot with "boot -v", the device is reliably detecte= d
correctly.=C2=A0 since -v shouldn't cause any functional changes, i sus= pect
this may be some kind of timing issue.

i've tried increasing some of the USB timings (hw.usb.timings.*) but this didn't seem to have any effect.=C2=A0 is there anything else i cou= ld try
that might affect this, or is this perhaps a known issue?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 thanks, lexi.


--
Nuno Teixeira
FreeBSD Committ= er (ports)
--000000000000ecd0160614f97a11-- From nobody Sun Mar 31 19:03:53 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 4V73Td121lz5GCyp; Sun, 31 Mar 2024 19:04:05 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V73Td0TJnz4N0P; Sun, 31 Mar 2024 19:04:05 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711911845; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6yxmJLwmoTc2g4XJpTu7/GwEy0N6nZgGrKXb5NZTUyA=; b=P0k3oJi4m/4y2101lDiMRT26NOtnb8Rz8VLtkL0/YSQEaRNwIy879hVvANhzxLZPZdy1Xr voJbTIcIJfIXfh4fIrgt9dNERU1re+TTVtJytS/JvFSMDrVZuyqdqQN5yX6aKjdpzyo+0w OLCOFYMMmChR3M20fTJWfO6WYOFjs3+DaioNRt0HvvHBj/lFXOyWoVxCp8Cj03rGsnq7v9 ghn46N0ptOHQ/j9jI3qk6SWni6k/z0E1qxyNPqJgo9lilaxYtYi2MGfvstd6kZUySCpHsF geXSmXuRzqUop+LRf/GFUZaVdWHOk+0sxnGCGyVBT1iBnhYmtPEYW9G+fE02fw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711911845; a=rsa-sha256; cv=none; b=h+G/TfkGhBvwSXwhQPLBNCjfuqwX1HtnqK5h+XD7IElhVhvr06RyTEcsm+Q9YnncY9zR3P i9wKC81ch9zvVnhoBFkOrIjmSFtgfWlMAX/StPWSUgW8WwsjM7bEXypxBDZj0RpufvDCD0 ngcIBxmtGoUYBz+4l9aLNXWZ1L9lkNXGJfEuHs1O0nrmKK7TwyNTQPIiKjoHYrvNkHX42E 48OUqxBDU/+Eu65X/TsvnoVLLz2M2H+rPHGcwVidz6yAzydRqmYlHNEmajMvtpk9FayBRW AamMpQ23gUDabTwM79WTVuanNjNhnh/K+c5mX/lBzQUPoFbTxdlfnbPRDVtUCg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711911845; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6yxmJLwmoTc2g4XJpTu7/GwEy0N6nZgGrKXb5NZTUyA=; b=V27kQD3/Zc4MtZbgfuqSy/NiN5CspTImdSwcI762iCfHkSpZP1d717DdimCUMbM3aVD/9T 1Xk720ZjUwXSE4MVLk5AY0vyetK87jSnDn/57PXH1/8m5dNDh+9JZ9TrtjURvmDPKind3/ wRHG2RJojzkE+oCC84Lk7m2u4Pka9wxgmqUPP68SO4sBqTUdKKpgpKYSGjHA1qJekYBVwz XT/Fi+w1exu86CEq6u9GkncuH6GREwI5CGBzdejOpOFrNBy8Azfwk4HCMjNWu7xzu1SeVA OGlxCpzJDhelPqyAdcgMuGj/jMvNOILrOEQO00g8A+4Sa9AkFtFCl8p7FNQObQ== Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4V73Tc73XZzXl1; Sun, 31 Mar 2024 19:04:04 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-432d5b5f00bso6750011cf.0; Sun, 31 Mar 2024 12:04:04 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCU4l7N4PjkFwR8QF/7/OYxqSl3zskIVTiWQ4AHe7AGj85Ce02LRa7v1Nqydp2LQk0ew2/0b/1d/iPCHwsF8eUMeCgelJS5fpS01n4w= X-Gm-Message-State: AOJu0Yz+jVKYuJD7cPscVEyNcIiQ9/n8JXOmSJaCaNx64ucYN3NB7W4e CNw55X+AJHWR7509k1Yi6rTbfwuMoFRtBwqzh2arWxNrsfqgpaxay5u8+N5pzOHx7lbs3YEseV3 lP7MyxS7/EDCAM0OK4IXpIL2ApZI= X-Google-Smtp-Source: AGHT+IH6Dekn+UzHFNkLtxFvYO4bW1Xtg+4IJnQZvoonQD+Sdwt7Q0fEmhT/4GZmpxOHi/gbSaIfii3gVzmyJOMDfU4= X-Received: by 2002:a05:622a:1490:b0:432:ccd8:1723 with SMTP id t16-20020a05622a149000b00432ccd81723mr8416514qtx.9.1711911844434; Sun, 31 Mar 2024 12:04:04 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Nuno Teixeira Date: Sun, 31 Mar 2024 20:03:53 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: 15.0 on RPi4, USB broken: uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000005fe5480614f98990" --0000000000005fe5480614f98990 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (...) initial_turbo https://www.raspberrypi.com/documentation/computers/config_txt.html#overclo= cking Nuno Teixeira escreveu (domingo, 31/03/2024 =C3=A0(s) 19:59): > Hello, > > If you got a fan in your rpi4 box, you could try to overclock it. > If not, there is a funcionality in config.txt to overclock it just for a > few seconds at boot time. > > I can't remember the funtion but I'm looking at: > https://www.raspberrypi.com/documentation/computers/config_txt.html > > Cheers, > > Lexi Winter escreveu (s=C3=A1bado, 30/03/2024 =C3=A0(s)= 19:45): > >> hello, >> >> i'm using 15.0 (f66a994d59) on an 4GB RPi4 with a USB<>SATA adapter for >> the root disk: >> >> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device >> ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA (0x174c:0x55aa) >> ugen0.3: at usbus0 >> umass0 on uhub1 >> umass0: > 2.10/1.00, addr 2> on usbus0 >> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >> umass0:1:0: Attached to scbus1 >> da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 >> da0: Fixed Direct Access SPC-4 SCSI device >> da0: Serial Number 123456789019 >> da0: 40.000MB/s transfers >> da0: 228936MB (468862128 512 byte sectors) >> da0: quirks=3D0x2 >> >> when connected via USB 2, this works fine. when connected via USB 3.0, >> the device sometimes fails to attach on boot, causing mountroot to fail. >> i can reproduce this reliably with both GENERIC-NODEBUG and a custom >> modular kernel, and sometimes (but not every boot) with GENERIC. >> >> when the problem happens, with USB_DEBUG enabled, the kernel logs: >> >> uhub_reattach_port: port 2 reset failed, error=3DUSB_ERR_TIMEOUT >> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2 >> >> however, if i boot with "boot -v", the device is reliably detected >> correctly. since -v shouldn't cause any functional changes, i suspect >> this may be some kind of timing issue. >> >> i've tried increasing some of the USB timings (hw.usb.timings.*) but >> this didn't seem to have any effect. is there anything else i could try >> that might affect this, or is this perhaps a known issue? >> >> thanks, lexi. >> > > > -- > Nuno Teixeira > FreeBSD Committer (ports) > --=20 Nuno Teixeira FreeBSD Committer (ports) --0000000000005fe5480614f98990 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nuno Teixeira <eduardo@freebsd.org> escreveu (domingo, 31/03/2024 =C3= =A0(s) 19:59):
<= div dir=3D"ltr">
Hello,

If you got a fan in yo= ur rpi4 box, you could try to overclock it.
If not, there is = a funcionality in config.txt to overclock it just for a few seconds at boot= time.

I can't remember the funtion but I'm looki= ng at:
https://www.raspberrypi.com/documentation/= computers/config_txt.html

Cheers,

=
Lexi Winte= r <lexi@le-fay.org<= /a>> escreveu (s=C3=A1bado, 30/03/2024 =C3=A0(s) 19:45):
hello,

i'm using 15.0 (f66a994d59) on an 4GB RPi4 with a USB<>SATA adapt= er for
the root disk:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device ASM= 1153USB3.0TOSATA ASM1153USB3.0TOSATA (0x174c:0x55aa)
ugen0.3: <ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA> at usbus0
umass0 on uhub1
umass0: <ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA, class 0/0, rev 2.10/1.= 00, addr 2> on usbus0
umass0:=C2=A0 SCSI over Bulk-Only; quirks =3D 0x0100
umass0:1:0: Attached to scbus1
da0 at umass-sim0 bus 0 scbus1 target 0 lun 0
da0: <ASM1153U ASM1153USB3.0TOS 0> Fixed Direct Access SPC-4 SCSI dev= ice
da0: Serial Number 123456789019
da0: 40.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2<NO_6_BYTE>

when connected via USB 2, this works fine.=C2=A0 when connected via USB 3.0= ,
the device sometimes fails to attach on boot, causing mountroot to fail. i can reproduce this reliably with both GENERIC-NODEBUG and a custom
modular kernel, and sometimes (but not every boot) with GENERIC.

when the problem happens, with USB_DEBUG enabled, the kernel logs:

uhub_reattach_port: port 2 reset failed, error=3DUSB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2

however, if i boot with "boot -v", the device is reliably detecte= d
correctly.=C2=A0 since -v shouldn't cause any functional changes, i sus= pect
this may be some kind of timing issue.

i've tried increasing some of the USB timings (hw.usb.timings.*) but this didn't seem to have any effect.=C2=A0 is there anything else i cou= ld try
that might affect this, or is this perhaps a known issue?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 thanks, lexi.


--
Nuno Teixeira
FreeBSD Committ= er (ports)


--
Nuno Teixeira
FreeBSD Committ= er (ports)
--0000000000005fe5480614f98990-- From nobody Sun Mar 31 19:10:59 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 4V73dy1gRpz5GDQ9 for ; Sun, 31 Mar 2024 19:11:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.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 4V73dx1TqSz4Q2h for ; Sun, 31 Mar 2024 19:11:17 +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=1711912274; bh=cKB0Ke71kU9qZTFdWjLp2YjKnnTNaWAwrieXTF0bruE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ReSLDgRDQCoDk9FqnkMYTiNmUil0VWg0i7KYKzda69CUgqnkAizU4MI2elwzzOVLPQtSTb2qzdZk00mDu39/m6KkbyKOLz/3IOLpXcvkeO6sha+zIKxKbK4N+mMIhbxse69lZydvFGLuBzeG2F2n2/0nRmXlhjQ6i9GveAW9ABZlOR/T1Udag9U1WhQl4Zo91GJ1LjaUqeMx1vK5Tujf3Jszbg87j3/mSpwOOJmkyYqcIp6DecS5BQEt+RALUdZ3R9cmllOXinth54feRBpWKtWd9xiuBn2OjklNRy4RGTQwuojwA+Bf+LFewamqNuO5qIPkJqtH1CffPiaYHhCvEg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1711912274; bh=pjZI8rKNTHMzd7QDIucBguoh2aEa3CFQOZlsN4wkQmu=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hejb6YxqCNtDl/S3NJwTktbJEVNWnEVh/XJ7R1jsHh7Cdm7RlYU3sap6t2ZAaiPbhBROlzJVpDSwNiFpsE/hyoAkn+OJeWBCM7F/NJxVdxOQ+CzqJhKc6+K1/Nb7YvM+1WYBaBBrl6zWaQixUlQmWMw8RgJeHhQzO6RnIWvlzQKuv/f/W9EzSyKRUhlws1jZXwWHXWfQBenJos/D79V8G42IYFTIJy5A/eBiFJLFGXWIwqLtFNRA281ul4cvFEGQzmEjYT67oOWwL/Ad/MvSUIZDuX13+LjR9N2zMXsDgmNBDGB/tewVs4I6YhTph6a0/2VAUMTzdkJnMQ5VphWhtQ== X-YMail-OSG: 7IMddUYVM1kfdC2f84.T9kOblUHs_YBRzxDjP3uBc8MaOIUF_lenzX5X_k6OkLl idFv7bDQxcFL8g9Gptzo4M3xtk7Omgh.OOTTOn9FYBmyVotKBa_nFPtdEfgTTUMkuwUGEyuFS2sj w3.9TmWhQFYx9ClijhIKfDYXBdXXYMkCa5TlesK44viJTLwO5jJzXuRwPQLPTw1bAsdZJxW2VjG6 3VcX97Icr6b8TNsEld1HpjjIoLcEGp3Es.YQFtkljDzzhDGkZXNEX969yPrAysVf_42Cx4SzwDFL RBLVMORiiCHNFaYeTyAs8GkL_cr2JUsv6A5LlNnf5.fW0za13IB9gsalEkrYoFAAyW5KLSP4qhdk 6Y8radkuHyONH3n3GOJ9Imwp0jc3mcggI2CYg6p77lNt8sM4RX.hEFKnA22LGtMPMQdbEpg1Ce4v RKHJDuCCVk.mz4ZMAlVdAmrO.zF3aSevNG.iA05FjLUeTSaxUlgIat5n0MR0Roilt0KqzrPSKVot mgrwrxZ_RtNO.dNURuCRWblkxM8NoelM5lE88igRqr0HNBo_ghPKLlxPDKeIngBF79X3DoekX0eM PbOQuoePG3PJZ8_1XFViAfvuo8xFp3RlzhuB6KyEB8g6QtCpTr.WT80vwuqII4LJv5JktHYD5MKK 052I2Lnxv71jayKWw2MYXZHX7nnOCFxs8cm07nEHjVRoYjtpCTSohnNPrPzBV3dmAlGRq2nKztLW qc63CyEDQD3n9ovwDiyeGOUszqcbl1BKjZnPEl3d0AQ_MYagzoBg8VZvQ1wn.mATQqZyhatE3C6c B5Bh9t1u432_pyUnfLijbBJXfzfpU4sVYBnDwa5R8DRGRLzHJ_8ON8ddP59mQ1BZ7ZYoGyUzOFXv 8TMZCMmJUP8qKwS_7hs.I3cjIFhoGbol0rSB7SXWyGhn0S45Xgb5KDhL9h1Qhm9D6U2enxZjsjlx f9UuTh_g2AZpViQ3h8tUJByfoWCJKtVsnLwrTPWmc14nZuUlork8sIMMettAyUKymY8066evyQVE xum3cqZU8gAYHHC6XIFRjzgHZvz5sDR.J4FYLW39N2Bw2op9f7iDybGWhqGOq1h3Y3_kMIY1noLP 5LvU1gfDT3modhnwDN9S2zOmDlsAY7mgqK.VAIhm6wDISl6_UJkeaMtLlOgrL6NHeFkyGqA3eUma re_9f2Vm.4.znq.S.rn2iamNxdKuRkCKldCjfEpFfrNLz8.SLdouYWke.yvzz3q3RXsbGO4H5wvQ ShTTSvPsobJ2h.KnNczL1ZJpSjdP9id4IedBt5VlBnLTG5aQUu7UAp0.0_OCxAVfiMLx8WXvSAE. Zb2R_Bk6Z3YGRZLozpZyom3wdLCr_BoWcLSpAHKcrN2MwpZJ1sdEzLHTbB56Sav8M6_qXBMxTGbx yVLe.etLS0zcGj3YAkXhdMRtZ08s3Fv68dHbXTJIH1vevD93eKlUNcZ1e8N9BQbLem8H8480hIxA DkmM7Hy0IobuRJdD8tg4m6jWlIoEWyie004HeAUfxBuHAydgoCk8nnsTrMDGW0Fh2rWEdwoDv8tL kDBAE4LXh8badM5qdmj99oIiqgJKiB_O.zVNNnN3CXNRmzsIx8p88DXAYWuQy7X_qnFVXRkDzvQF xv.IZl.I9w4lVTKoqtCZtkTYNRkyIlLLBr8LEqmIl7caME1E05SNRRchoAgqFAAeJmdP_QGIi5TY 82Z.OE9h4blojH6QlYFoDhDSTJdTXC8wTvhFizrtQUBKOGLjVJATEzOXWn53R73pcTh1aJL9zSIS 3EQnPKvALLeQqrR30vOPIHfimSxkshc8gujuGrQ69LDxfcGqqCJ6BKybw.p10TTl09XMI5tGw8uU xHQmwS0bYyt5vn4r6lFBw1ADi87QsWgGYpCvr2iArdN0a1thlc6QqrlWL81qdMKI2LlE59mDhnYU 1bC16ry4_RTun0Vs6m6IBfGaSXKBqYeyELpOUjPbilbVRAF0LCM_UFPy1yR.E5dzXkuRJpa7UGC_ uVC0fF13k8U2bcCvq_7X40pudYLU2t_RlYmloJ4rvIfqtfSR_n91.E7VU8O0conY7cBJ5a57A2AO vgIToPKmdT8wPzLyeJo3szJuOnxTThlVbnD78NWcqxEx2YpeQw.SI5Bu_.HcSCAxL41Ii5lH3sU7 GrDBfKWexrcF.vcC_PVilXgoRZC9krZQTPwJRjg.rSzz8lrOog1IL9rIsNnZmCoHjdrlSgaMqole PMLR1M9h6.eBL3X0Z95.KDbbC1G7qh3pTaKvl1VZJjiLsFhaXaToOC9iCIMPTocTfUu0MPnzXrSh 9VVY- X-Sonic-MF: X-Sonic-ID: 616da6de-f310-4685-99d3-cedefc5295d8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 31 Mar 2024 19:11:14 +0000 Received: by hermes--production-gq1-5c57879fdf-6xjwd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c93635af89178c64b05616b06b892ffc; Sun, 31 Mar 2024 19:11:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: 15.0 on RPi4, USB broken: uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT From: Mark Millard In-Reply-To: Date: Sun, 31 Mar 2024 12:10:59 -0700 Cc: FreeBSD ARM List , freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <04AA156F-129B-41C2-AB3D-B762585F8BC0@yahoo.com> References: To: Lexi Winter X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4V73dx1TqSz4Q2h On Mar 30, 2024, at 12:44, Lexi Winter wrote: > i'm using 15.0 (f66a994d59) on an 4GB RPi4 with a USB<>SATA adapter = for > the root disk: >=20 > usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage = device ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA (0x174c:0x55aa) > ugen0.3: at usbus0 > umass0 on uhub1 > umass0: on usbus0 > umass0: SCSI over Bulk-Only; quirks =3D 0x0100 > umass0:1:0: Attached to scbus1 > da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI = device > da0: Serial Number 123456789019 > da0: 40.000MB/s transfers > da0: 228936MB (468862128 512 byte sectors) > da0: quirks=3D0x2 >=20 > when connected via USB 2, this works fine. when connected via USB = 3.0, > the device sometimes fails to attach on boot, causing mountroot to = fail. > i can reproduce this reliably with both GENERIC-NODEBUG and a custom > modular kernel, and sometimes (but not every boot) with GENERIC. >=20 > when the problem happens, with USB_DEBUG enabled, the kernel logs: >=20 > uhub_reattach_port: port 2 reset failed, error=3DUSB_ERR_TIMEOUT > uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2 >=20 > however, if i boot with "boot -v", the device is reliably detected > correctly. since -v shouldn't cause any functional changes, i suspect > this may be some kind of timing issue. >=20 > i've tried increasing some of the USB timings (hw.usb.timings.*) but > this didn't seem to have any effect. is there anything else i could = try > that might affect this, or is this perhaps a known issue? >=20 Here is my config.txt material related to such issues: # # Local addition that avoids USB3 SSD boot failures that look like: # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port = ? # WARNING, not sufficient for "boot -s": that needs the full = force_turbo=3D1 initial_turbo=3D60 As far as I can tell, without using one of the turbo settings, the more modern RPI firmware is varying the speed of the clock in the early boot time frame and FreeBSD is working in a way that requires more uniformity for such. (May be delays based on just loop counting?) =3D=3D=3D Mark Millard marklmi at yahoo.com