From owner-freebsd-arm@freebsd.org Sun Jan 17 03:25:57 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0C3134D971B for ; Sun, 17 Jan 2021 03:25:57 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJL0h1DhPz3qZW for ; Sun, 17 Jan 2021 03:25:55 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x42e.google.com with SMTP id y17so13162326wrr.10 for ; Sat, 16 Jan 2021 19:25:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=w1q5afE7vN0ByeRJQ/4r2K+Yco7nfDdtK08M42gFEPE=; b=Lo9GoaXVGQcfmsv5Iyud6ZAz62R4cDJqwDH3nQEj8Un65H/BUzLjlqKL/0/gn75NVJ pxkx+lTXojEYDmyfGmrlGCtUea+jvyiBFUFo/1TK0fTjR2W92f4URjcozvuzW/iRnPfw UcIMn2xm5ZzFq+X6ADHls4feesMxQLy8MKwg2Th537bPE9W/NwLvB91yM3zY2TRcYu0J PLcTPDR2YmoiK5OwRVS1V3d0Xx3cFlW23T2vKLXMjEX++SOugd6wEkcxv/59dEv2wJy8 Nn9p2n9j40rTNz5GWehk4SJhawNTT4if+4LLlT3Kv+jPeXC9CIwvDLHKIDxFndHRqINI PBwg== X-Gm-Message-State: AOAM532ZAhd7q5p4vzxl7MnTfqpNYmu9fBUMkIMZEAMhIgUDwnzYIGKh SkOOnaQuhdR7rP3VKZWNeSoGF+u6dge4JQ== X-Google-Smtp-Source: ABdhPJxX325JYJzhCJaPzm24EuTB0dITlxPvRsIvlFpYZrhUuFHWAHdPpvL/UqOFO8qI34NDRWXLTg== X-Received: by 2002:adf:fa86:: with SMTP id h6mr19739716wrr.103.1610853954458; Sat, 16 Jan 2021 19:25:54 -0800 (PST) Received: from [192.168.1.167] (dynamic-046-114-104-148.46.114.pool.telefonica.de. [46.114.104.148]) by smtp.googlemail.com with ESMTPSA id c190sm17663399wme.19.2021.01.16.19.25.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Jan 2021 19:25:53 -0800 (PST) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Getting RPi4b (8GB) to boot from a microSD card? Date: Sun, 17 Jan 2021 04:25:51 +0100 References: <20210116223141.49336596dcac9970e3c0442b@getmail.no> <20210116232736.2002f4dd4a18faa6beed0289@getmail.no> To: Torfinn Ingolfsen , freebsd-arm@freebsd.org In-Reply-To: <20210116232736.2002f4dd4a18faa6beed0289@getmail.no> Message-Id: <2868BA35-B046-4EC4-B0B7-A6B0717E1EE4@googlemail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DJL0h1DhPz3qZW X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::42e:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.104.148:received]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::42e:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 03:25:57 -0000 > Am 16.01.2021 um 23:27 schrieb Torfinn Ingolfsen = : >=20 > ... > ok, with updated firmware (same way as the other images) this image = now boots. Unfortunately, usb doesn't work, so no local keyboard. ssh = works fine=E2=80=A6 You may have to do an eeprom update: = https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.= md If nothing has changed in the meantime in bcm2711-rpi-4-b.dts/dtb, you = can use the following if you want to boot from USB via u-boot: https://reviews.freebsd.org/D26853 K. From owner-freebsd-arm@freebsd.org Sun Jan 17 08:42:29 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 952A44E0FE3 for ; Sun, 17 Jan 2021 08:42:29 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJT1w67WDz4c7W; Sun, 17 Jan 2021 08:42:28 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: by mail-lf1-x12b.google.com with SMTP id b26so19627600lff.9; Sun, 17 Jan 2021 00:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=77cms4hwcy9U5LkKLdUiEH0ZU5fbr5DvxLq7Eys9tfw=; b=jLdJ3CSroU/8A7elOFy3sl0YmLj6zl3q9+rkPEriYFOFe++hblz3IdNcQE8G9VpW1b jHDcY+qaaqBgulu7s+523cyGK8Vji2RmSPXn+zpGFOgjEok+Dayy0Yie0EWXvIG8KtGD EDdKebl5eMeBMR09NDKpfTCbbZnrEQGSdbygkL6ow6Q57ShHYbLnfKO2OUMCzo2/qWiE FNjw1KeytjTxtRQDyWzwQ+dcsR5/CBdr3oyrSR6RGUB/92R2CBxka0xsfFCsGPGnV5m9 nekMxSKqC+ZUhSp8nS4zomdmUo8H7Hq3XoV8r5iNGzZ+s7hA1rfhWc3FZAfDsltoqnS0 8Dng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=77cms4hwcy9U5LkKLdUiEH0ZU5fbr5DvxLq7Eys9tfw=; b=DSHZzz8yRAJdTuxo+a7P0JIcPWiOhWLEg32kTvU4ARIx09j7ek3jJc/VXZlRn09RLT LVUrcqcT00vDMNJSmIfDEHPWWiFHRlMc6+F4RhRcXPJzbml+7eICUrXIV4sGRaTRB7ex 0LNs7PSh740l8YErhicT4iFgF4gdSixBnQ8YqGkYmUjieah6DtePioFvT6JrKPkyjZvz xjQY9tXXEJeD68ZGOlNuV4U3gMTlDzDjafEmrJmVQuFZ3JlfZAM2Waru05AWX/IZ51LG 3NJEFRy344rUDJL0/WSZ7vQnmaBkZwkmhVAb76ZrQMGqFSBFYMutDE/qAKyKt6IWy9xE m4Yg== X-Gm-Message-State: AOAM5321GLg/18/QalP6iRTlkRkZZ7epslhxGy6d5Unw0uaIDp60cgDV mdc/yexrlaOYtrUesiyh7EttVkOD4S+ebw== X-Google-Smtp-Source: ABdhPJxBBvfIAC/iLBiFalRuNKWqhxj3uIiQtSixE2CoGCluztQkl9bLPFRCq7dBc7+BdpHhhwFc5g== X-Received: by 2002:a19:4148:: with SMTP id o69mr8533464lfa.610.1610872946683; Sun, 17 Jan 2021 00:42:26 -0800 (PST) Received: from [192.168.1.156] (128-69-179-113.broadband.corbina.ru. [128.69.179.113]) by smtp.gmail.com with ESMTPSA id q9sm1344975ljm.113.2021.01.17.00.42.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Jan 2021 00:42:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Sleep Walker Mime-Version: 1.0 (1.0) Subject: Re: ZFS problems on aarch64 (RockPro64) Date: Sun, 17 Jan 2021 11:42:22 +0300 Message-Id: <43CFD9F6-6CCF-4F79-8BF5-3CCD6A28DA86@gmail.com> References: <2b0ed525-ff96-d1ce-bb11-d3352c380bf7@freebsd.org> Cc: freebsd-arm@freebsd.org In-Reply-To: <2b0ed525-ff96-d1ce-bb11-d3352c380bf7@freebsd.org> To: mmel@freebsd.org X-Mailer: iPad Mail (18C66) X-Rspamd-Queue-Id: 4DJT1w67WDz4c7W X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=jLdJ3CSr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of s199pwa1k9r@gmail.com designates 2a00:1450:4864:20::12b as permitted sender) smtp.mailfrom=s199pwa1k9r@gmail.com X-Spamd-Result: default: False [-3.44 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.94)[-0.938]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::12b:from]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[128.69.179.113:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::12b:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12b:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 08:42:29 -0000 Thanks, this patch helped everything works, pools are created =D0=9E=D1=82=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=BE =D1=81 iPad > 16 =D1=8F=D0=BD=D0=B2. 2021 =D0=B3., =D0=B2 16:47, Michal Meloun =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >=20 > =EF=BB=BF >=20 >> On 16.01.2021 12:12, Sleep Walker wrote: >> The problem is confirmed tested today on the Kobol Helios64 RK3399 NAS. > Can you, please, test the following patch? >> https://github.com/strejda/freebsd/commit/f6f7fbcb1c799504585ab6213c163b4= 91fec4e87 >=20 >=20 > Thanks, > Michal >> root@helios64:~ # gpart delete -i 4 ada0 >> ada0p4 deleted >> root@helios64:~ # gpart add -t freebsd-zfs ada0 >> ada0p4 added >> root@helios64:~ # zpool create -f -m /mnt/sata tank-sata /dev/ada0p4 >> ahcich0: DMA load error >> (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 00 10 02 40 09 00 00= 00 00 00 >> (ada0:ahcich0:0:0:0): CAM status: CCB request was invalid >> (ada0:ahcich0:0:0:0): Error 22, Unretryable error >> cannot zero first 4096 bytes of '/dev/ada0p4': Invalid argument >> root@helios64:~ # uname -aUK >> FreeBSD helios64 13.0-CURRENT FreeBSD 13.0-CURRENT #0 de1aa3dab23c-c52890= 9(master): Sat Jan 9 17:54:57 MSK 2021 root@honeycomb.local:/usr/croche= t/work/obj/usr/crochet/src/arm64.aarch64/sys/EXPERT-13 arm64 1300132 130013= 1 >> root@helios64:~ # zpool list -v >> NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP = HEALTH ALTROOT >> media 9.09T 1007G 8.11T - - 0% 10% 1.00x = ONLINE - >> gpt/disk3 9.09T 1007G 8.11T - - 0% 10.8% - = ONLINE >> tank-emmc 14.5G 126K 14.5G - - 0% 0% 1.00x = ONLINE - >> mmcsd1p1 14.5G 126K 14.5G - - 0% 0.00% - = ONLINE >> tank-usb 14.5G 126K 14.5G - - 0% 0% 1.00x = ONLINE - >> da0p1 14.5G 126K 14.5G - - 0% 0.00% - = ONLINE >> zboot 63.5G 2.47G 61.0G - - 17% 3% 1.00x = ONLINE - >> ada0p3 63.5G 2.47G 61.0G - - 17% 3.89% - = ONLINE >> root@helios64:~ # >> Pools on ada0 were created 4 months ago. And they worked perfectly. >> On USB and eMMC everything works without errors even now. >> =E2=80=94 >> Sergei Tyryukanov >>>> 16 =D1=8F=D0=BD=D0=B2. 2021 =D0=B3., =D0=B2 11:01, Andrey Fesenko =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >>>=20 >>> I saw a similar problem in the same way, unfortunately, this platform >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sun Jan 17 14:25:52 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E8EFE4EB048 for ; Sun, 17 Jan 2021 14:25:52 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from SMTPOUT05.DKA.mailcore.net (smtpout05.dka.mailcore.net [81.7.169.178]) (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 "smtpout05.dka.mailcore.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJcf760rQz3GTk for ; Sun, 17 Jan 2021 14:25:51 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from SMTP.DKA.mailcore.net (unknown [10.1.0.52]) by SMTPGW.DKA.mailcore.net (Postfix) with ESMTP id 1955C42A18 for ; Sun, 17 Jan 2021 15:25:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=webmail.no; s=mailcore; t=1610893549; bh=6sq8KYVqc0puQ6czBl9ZyhlsJhkD+v6HY8weqB1j44E=; h=Date:From:To:Subject:In-Reply-To:References:From; b=Vs30H+52qfOiVlvKBIg6x83tiI7MapvGJdbbK+bC4LrNNPUIgFmRTXyjk4bN2mxl8 edvdQDgE6M0S1uV4ihV75cbMgXVzlcFk9Tg/I5QKvRbu2VwsiO2AAjVdyA04pBsdYi LdFbxZSkaZCA+CZByYrjv5SsWrwMPvDDk82EUhH0LtE3XNGbkKXT5ctQITZpKDnakt 3QtKyA8ZRb3RYZXD+V0WSmXmYO9Ary8oH5sBScS2APMmaG3E4T5aoKDJMh8tcoo7a1 PfsiDq3d547XmpWiT75TtKKDajrbg0yHWFefrd+cYVqnVyl17OCEX4dstb0ZHeoDJj Vff/AGAck4RlQ== Received: from kg-core2.kg4.no (unknown [178.74.2.42]) by SMTP.DKA.mailcore.net (Postfix) with ESMTPSA id 066A6400F1 for ; Sun, 17 Jan 2021 15:25:49 +0100 (CET) Date: Sun, 17 Jan 2021 15:25:48 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: Getting RPi4b (8GB) to boot from a microSD card? Message-Id: <20210117152548.30ab864e92385bd4ced120f7@getmail.no> In-Reply-To: <2868BA35-B046-4EC4-B0B7-A6B0717E1EE4@googlemail.com> References: <20210116223141.49336596dcac9970e3c0442b@getmail.no> <20210116232736.2002f4dd4a18faa6beed0289@getmail.no> <2868BA35-B046-4EC4-B0B7-A6B0717E1EE4@googlemail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd11.4) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4DJcf760rQz3GTk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=webmail.no header.s=mailcore header.b=Vs30H+52; dmarc=none; spf=pass (mx1.freebsd.org: domain of torfinn.ingolfsen@getmail.no designates 81.7.169.178 as permitted sender) smtp.mailfrom=torfinn.ingolfsen@getmail.no X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:81.7.169.128/25]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[webmail.no:~]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[81.7.169.178:from]; ASN(0.00)[asn:16095, ipnet:81.7.128.0/18, country:DK]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[getmail.no]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[81.7.169.178:from:127.0.2.255]; R_DKIM_PERMFAIL(0.00)[webmail.no:s=mailcore]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 14:25:53 -0000 On Sun, 17 Jan 2021 04:25:51 +0100 Klaus K=FCchemann wrote: >=20 >=20 > > Am 16.01.2021 um 23:27 schrieb Torfinn Ingolfsen : > >=20 > > ... > > ok, with updated firmware (same way as the other images) this image now= boots. Unfortunately, usb doesn't work, so no local keyboard. ssh works fi= ne? >=20 >=20 > You may have to do an eeprom update: > https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom= .md >=20 According to rpi-eeprom-update under RaspiOS, my Pi4 has the latest product= ion (=3D "critical") firmware: tingo@silent-pi4:~ $ sudo rpi-eeprom-update BCM2711 detected VL805 firmware in bootloader EEPROM BOOTLOADER: up-to-date CURRENT: Thu 03 Sep 2020 12:11:43 PM UTC (1599135103) LATEST: Thu 03 Sep 2020 12:11:43 PM UTC (1599135103) FW DIR: /lib/firmware/raspberrypi/bootloader/default VL805: up-to-date CURRENT: 000138a1 LATEST: 000138a1 Do I need something newer than that (from STABLE or BETA)? Looking at the r= elease notes, they talk about USB MSD, not anything about usb devices like = keyboards and mice. > If nothing has changed in the meantime in bcm2711-rpi-4-b.dts/dtb, you ca= n use the following if you want to boot from USB via u-boot: > https://reviews.freebsd.org/D26853 >=20 Will that give me a working local (ie. usb) keyboard? --=20 Torfinn Ingolfsen From owner-freebsd-arm@freebsd.org Sun Jan 17 15:33:00 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C68EB4ECAEA for ; Sun, 17 Jan 2021 15:33:00 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJf7b6gGmz3Lw8 for ; Sun, 17 Jan 2021 15:32:59 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x431.google.com with SMTP id 6so6784183wri.3 for ; Sun, 17 Jan 2021 07:32:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=5TnyeLzvD/u7mwPgfUvY5x3k9Vmv82zNFYYRyOB0kSI=; b=QZEHHMRaWELBSI+vOt+DOwgAG7w5W5qjh0pvxVhM6xwsCYRMfH+SC3ZVt7kgHsTB3b gaRVvlqpGET02OZHLiCo+EvYyqHEP0KPAnoEnGFxlVex6heEO/7PwqJGbw/lR7NxtWWX fgEStjdeoDguYA6LQiqo50Q6MODA5j9AJa8fnKn7iN1L59NFJM/IpWtiBkPtZXFc11Px o1yQuxhiDKaSKzFMlKpqtkAkZYRhG9Ltrp/WlIFgx6GKZlyk9h9WxqG2tqbORcUEvXDa dRMPlqhqGnKsuASp4046K6x8UYOvnQ+DyEQuKMzEqgnexwIdI1OjpA+J1Myp+bCHPZYZ cLzQ== X-Gm-Message-State: AOAM531aUuLR2N2uWsNRBhtQVx9AHjbgURSzrxfRsN+XAaZdiOIVcyst jE5pOeyxH90gu8A+lQz8XNM= X-Google-Smtp-Source: ABdhPJzQ8RWw2YvOiwSuO4vNGhSx7KvXLqKLMAqF2BoCzzwRolixApwnC+pxS1nbPQv/2REwBvAleg== X-Received: by 2002:a5d:4905:: with SMTP id x5mr21953597wrq.75.1610897578594; Sun, 17 Jan 2021 07:32:58 -0800 (PST) Received: from [192.168.1.167] (dynamic-046-114-110-028.46.114.pool.telefonica.de. [46.114.110.28]) by smtp.googlemail.com with ESMTPSA id z63sm21449549wme.8.2021.01.17.07.32.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Jan 2021 07:32:57 -0800 (PST) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Getting RPi4b (8GB) to boot from a microSD card? Date: Sun, 17 Jan 2021 16:32:55 +0100 References: <20210116223141.49336596dcac9970e3c0442b@getmail.no> <20210116232736.2002f4dd4a18faa6beed0289@getmail.no> <2868BA35-B046-4EC4-B0B7-A6B0717E1EE4@googlemail.com> <20210117152548.30ab864e92385bd4ced120f7@getmail.no> To: Torfinn Ingolfsen , freebsd-arm@freebsd.org In-Reply-To: <20210117152548.30ab864e92385bd4ced120f7@getmail.no> Message-Id: X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DJf7b6gGmz3Lw8 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::431:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.110.28:received]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::431:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 15:33:00 -0000 Hi Torfinn, your eeprom is O.K.,=20 I have now checked the current upstream state of Firmware : >> bcm2711-rpi-4-b.dtb is meanwhile O.K. upstream , so I abandoned=20 >> https://reviews.freebsd.org/D26853 What is currently NOT O.K:=20 fixup4.dat AND start4.elf in upstream . So you should be fine with reverting fixup4.dat AND start4.elf to older = version. If you don=E2=80=99t have compatible files available just now,=20 You can download older versions here : https://sourceforge.net/projects/d26853-bcm2711-rpi-4-b-dtb/files/=20 (inside the rpi4_pack_freebsd.zip) This should boot up your rpi fro USB/SSD & of course give you access to = your keyboard. Regards K. > Am 17.01.2021 um 15:25 schrieb Torfinn Ingolfsen = : > =E2=80=A6=E2=80=A6.. From owner-freebsd-arm@freebsd.org Sun Jan 17 16:24:45 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 732414EEF84 for ; Sun, 17 Jan 2021 16:24:45 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from SMTPOUT05.DKA.mailcore.net (smtpout05.dka.mailcore.net [81.7.169.178]) (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 "smtpout05.dka.mailcore.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJgHJ28FBz3PmZ for ; Sun, 17 Jan 2021 16:24:43 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from SMTP.DKA.mailcore.net (unknown [10.1.0.53]) by SMTPGW.DKA.mailcore.net (Postfix) with ESMTP id 36CA442A01 for ; Sun, 17 Jan 2021 17:24:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=webmail.no; s=mailcore; t=1610900681; bh=t4fXjSShsVFVT2Awu4XIBkI9Zkbr7nyxCa3HLW437Ts=; h=Date:From:To:Subject:In-Reply-To:References:From; b=aFS3gHDx4hN1fslTZwKjbfGl0ZceyqhBi/gHsq+6NQnyY94K47HGYeeNTRaB1g8nV kNqsHI0Ph/KkjTC/Sq1wTLwS+PRStp1l2pFV+sSgj8+IGfPFuGgJlYzlyLYd39b/Dw YKZNHHzPsWBF3miO0jvn/BxL3keuVf9OHiq6ZRNePi4IFTuOdH2sA8L+kBg85+ugVK Ep/EMdMyz/Dn7W2ZTtx85VUt1dKqdF4tkPE3SCmEywAebSWwalfL5lka0nJ0Bt3liB ib9Oj8PSU8GUFVPPq03wLOJp0m5kBNKACYmjBC1rww/GTu8p/ilL3FfmYtfzEQsVvQ A9XGGTdttQm/w== Received: from kg-core2.kg4.no (unknown [178.74.2.42]) by SMTP.DKA.mailcore.net (Postfix) with ESMTPSA id 247DC400F8 for ; Sun, 17 Jan 2021 17:24:40 +0100 (CET) Date: Sun, 17 Jan 2021 17:24:40 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: Getting RPi4b (8GB) to boot from a microSD card? Message-Id: <20210117172440.fea7f9ed48a68bc3faa90e66@getmail.no> In-Reply-To: References: <20210116223141.49336596dcac9970e3c0442b@getmail.no> <20210116232736.2002f4dd4a18faa6beed0289@getmail.no> <2868BA35-B046-4EC4-B0B7-A6B0717E1EE4@googlemail.com> <20210117152548.30ab864e92385bd4ced120f7@getmail.no> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd11.4) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4DJgHJ28FBz3PmZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=webmail.no header.s=mailcore header.b=aFS3gHDx; dmarc=none; spf=pass (mx1.freebsd.org: domain of torfinn.ingolfsen@getmail.no designates 81.7.169.178 as permitted sender) smtp.mailfrom=torfinn.ingolfsen@getmail.no X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:81.7.169.128/25]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[webmail.no:~]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[81.7.169.178:from]; ASN(0.00)[asn:16095, ipnet:81.7.128.0/18, country:DK]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[getmail.no]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[81.7.169.178:from:127.0.2.255]; R_DKIM_PERMFAIL(0.00)[webmail.no:s=mailcore]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 16:24:45 -0000 On Sun, 17 Jan 2021 16:32:55 +0100 Klaus K=FCchemann wrote: > Hi Torfinn, >=20 > your eeprom is O.K.,=20 > I have now checked the current upstream state of Firmware : > >> bcm2711-rpi-4-b.dtb > is meanwhile O.K. upstream , so I abandoned=20 > >> https://reviews.freebsd.org/D26853 >=20 > What is currently NOT O.K:=20 > fixup4.dat AND start4.elf in upstream . >=20 > So you should be fine with reverting fixup4.dat AND start4.elf to older v= ersion. Thanks - using older versions helped. > https://sourceforge.net/projects/d26853-bcm2711-rpi-4-b-dtb/files/=20 > (inside the rpi4_pack_freebsd.zip) Using fixup4.dat and start4.elf from this zip file works, with one caveat: = if the usb receiver for my keyboard and mouse (Rapoo E9100P) is in a usb port when the boot starts, the boot (at least some of the console = output) goes extremely slowly and eventually fails. If I insert it after the kernel has booted (after the login prompt shows up= ) the usb keyboard and mouse works normally. usbconfig output: root@generic:~ # usbconfig ugen0.1: <0x1106 XHCI root HUB> at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER (5= .0Gbps) pwr=3DSAVE (0mA) ugen0.2: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH= (480Mbps) pwr=3DSAVE (100mA) ugen0.3: at usbus0, cfg=3D0 md=3DHOST spd= =3DFULL (12Mbps) pwr=3DON (200mA) --=20 Torfinn Ingolfsen From owner-freebsd-arm@freebsd.org Sun Jan 17 16:39:59 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 889744EF684 for ; Sun, 17 Jan 2021 16:39:59 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJgct6Qrkz3QwN for ; Sun, 17 Jan 2021 16:39:58 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x32e.google.com with SMTP id g10so11824953wmh.2 for ; Sun, 17 Jan 2021 08:39:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=E8k4/9ifMSMNu0lEAh5jGtr3TePHLrE2qaOV0elEd4E=; b=Hi4qoGjWYL5iqW4dwJ5Go2Av4yZxVAkNEGwvZqlSxqW3n3lN15BKgMAdvAuIRQGUhJ UinKRUNlecVZfumQADGzzYgtejy0sTR42yIgDL8zM83eNHYYd0urre5OfixYGkbKiSlp gqEIDISKeI302Q1H0wREiRmbMagUXnogH/Aj2HCpfhfyzXFYcL8jbpDwMqq+Q5atvDlE 48n7lw4UO42M4J3+rKhIPHLrZBnH4yjN19D3YIH7j4GWUB7mXv2AgkrmBgQBr5ctuMst ggzOQ57aHdng0S6+Qa3CsweMyxn5777xWMDlPzzSvYGVawyKMbBR/sBTGPMEqCyDjg8p fR9Q== X-Gm-Message-State: AOAM532V5u4rW8sPgqLOJHTg9u/KLtTWucdNG9jqLiSuNtrmlRFuHJT7 0/ZKSMId1TAOsTHil75hgrTLKzPW+0rpgA== X-Google-Smtp-Source: ABdhPJyCl12cZTlks9C8haU4vhAvZnS/28jlc5JsNqINRuiidCysHov2uthobehwz36H/m9T+YQcKw== X-Received: by 2002:a1c:4e0a:: with SMTP id g10mr17308523wmh.51.1610901597303; Sun, 17 Jan 2021 08:39:57 -0800 (PST) Received: from [192.168.1.167] (dynamic-046-114-110-028.46.114.pool.telefonica.de. [46.114.110.28]) by smtp.googlemail.com with ESMTPSA id q9sm10643247wme.18.2021.01.17.08.39.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Jan 2021 08:39:56 -0800 (PST) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Getting RPi4b (8GB) to boot from a microSD card? Date: Sun, 17 Jan 2021 17:39:54 +0100 References: <20210116223141.49336596dcac9970e3c0442b@getmail.no> <20210116232736.2002f4dd4a18faa6beed0289@getmail.no> <2868BA35-B046-4EC4-B0B7-A6B0717E1EE4@googlemail.com> <20210117152548.30ab864e92385bd4ced120f7@getmail.no> <20210117172440.fea7f9ed48a68bc3faa90e66@getmail.no> To: Torfinn Ingolfsen , freebsd-arm@freebsd.org In-Reply-To: <20210117172440.fea7f9ed48a68bc3faa90e66@getmail.no> Message-Id: <89330786-DD5F-4C6B-9FCF-8370ADCA5BEA@googlemail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DJgct6Qrkz3QwN X-Spamd-Bar: / X-Spamd-Result: default: False [-0.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::32e:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.110.28:received]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::32e:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32e:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 16:39:59 -0000 > Am 17.01.2021 um 17:24 schrieb Torfinn Ingolfsen = : > =E2=80=A6 > . > in a usb port when the boot starts, the boot (at least some of the = console output) goes extremely slowly and eventually fails. > =E2=80=A6=E2=80=A6 I guess I know which boot-behavior you mean,=20 while it never failed for me(and of course shouldn=E2=80=99t), But for the slow boot up: If you press enter during the bootup(when it seems slow), it should boot = very fast, specially from SSD. If you still experience boot-fail, you could try to overwrite = bcm2711-rpi-4-b.dtb with the one from=20 the sourceforege-site for comparison . FYI: my keyboard sits in the bottom left USB-slot(I didn=E2=80=99t = compare with other slots) Regards K. From owner-freebsd-arm@freebsd.org Sun Jan 17 16:45:44 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 21C484EFA70 for ; Sun, 17 Jan 2021 16:45:44 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJglV3DHMz3h36 for ; Sun, 17 Jan 2021 16:45:41 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1610901939; 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=8+o9P0R2LQK8tHM8nu/sqpz1qljS/SlQjpvOVGQIn/w=; b=gMNUGN13ahIkohAgs5b0/YV7vlM8rSX/donIysl2TU7ZtLmVHiWletdot8At2NZq4ye779 08n8gbv1Xx8zrt4ClMRzNG0OSV7r5/wEbuQCYBq8JNH7mBF7mWeFGzzXXTJITCJE2JTPBo GoxtMQPqOPybR0DTdb5wyzubkl5EG8Y= Received: from skull.home.blih.net (lfbn-idf2-1-745-114.w86-247.abo.wanadoo.fr [86.247.192.114]) by mx.blih.net (OpenSMTPD) with ESMTPSA id adab4020 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 17 Jan 2021 16:45:39 +0000 (UTC) Date: Sun, 17 Jan 2021 17:45:39 +0100 From: Emmanuel Vadot To: "Dr. Rolf Jansen" Cc: freebsd-arm@freebsd.org Subject: Re: GENERICSD snapshot on a BBB has issues with loading the if_rtwn_usb module Message-Id: <20210117174539.43b55379e6a37881589616a8@bidouilliste.com> In-Reply-To: <06F689CA-B781-4CEB-8F8A-B00FAC684DD3@obsigna.com> References: <47700631-2D94-4BA8-9707-9ADD70C99600@obsigna.com> <20210116184333.f91594f9c3505d2c588d9634@bidouilliste.com> <20210116184833.1a3182a20a2b6c727b64bb59@bidouilliste.com> <06F689CA-B781-4CEB-8F8A-B00FAC684DD3@obsigna.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DJglV3DHMz3h36 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=gMNUGN13; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.20)[0.205]; SPAMHAUS_ZRD(0.00)[212.83.155.74:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.83.155.74:from]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 16:45:44 -0000 On Sat, 16 Jan 2021 15:11:28 -0300 "Dr. Rolf Jansen" wrote: > > Am 16.01.2021 um 14:48 schrieb Emmanuel Vadot : > > > > On Sat, 16 Jan 2021 18:43:33 +0100 > > Emmanuel Vadot > wrote: > > > >> On Sat, 16 Jan 2021 14:08:58 -0300 > >> "Dr. Rolf Jansen" wrote: > >> > >>> I updated one of my BBB from an older 13-CURRENT (July 2020) to the latest 13-ALPHA1 snapshot from Jan, 14th ? GENERICSD-20210114-7ae27c2d6c4-255938. > >>> > >>> I had successfully employed an USB-WLAN dongle based on the RTL8188eu chipset. I only added the following into /boot/loader.conf: > >>> > >>> if_rtwn_usb_load="YES" > >>> > >>> By that all dependend modules were loaded automatically in a snap. With ALPHA1 this doesn?t work anymore. After hours of troubleshooting, I got it working by adding the following into /etc/rc.conf: > >>> > >>> kld_list="if_rtwn_usb" > >>> > >>> The "Loading kernel modules:" takes apprx. 4 seconds, however, then the USB-WLAN device is enumerated correctly and it is ready to use. This makes me think that this uncommon huge delay is the culprit. I checked this with some snapshot thats I had installed already. The issue seems to have been introduced together with the switch to GENERICSD. A GENERICSD 13-CURRENT from end of December showed this issue already, while a BBB-specific snapshot (from November 2020) that I had installed on another BBB works as before by loading the modules in /boot/loader.conf. > >>> > >>> I don't mind to load the modules by the way of the kld_list directive in /etc/rc.conf. However, the unusual long duration of loading the module and its dependencies might be an indication for a more fundamental issue. > >>> > >>> Please feel free to ask me for doing more tests. > >>> > >>> Best regards > >>> > >>> Rolf > >> > >> I can reproduce that on my netbooted BBB. > >> The module is correctly loaded : > >> > >> Loading > >> kernel... /boot/kernel/kernel text=0x1b4 text=0x68d638 text=0x1c84f0 > >> data=0xb4070 data=0x0+0x258000 syms=[0x4+0xa5ab0+0x4+0x119fd4] Loading > >> configured modules... /boot/kernel/if_rtwn_usb.ko text=0xb960 > >> text=0x62c0 data=0x2cc+0x3b syms=[0x4+0x3570+0x4+0x293f] /boot/entropy > >> size=0x1000 /etc/hostid > >> size=0x25 Using DTB provided by EFI at > >> 0x87f00000. Kernel entry at > >> 0x96e00200... Kernel args: > >> (null) > >> ---<>--- > >> > >> But it isn't loaded anymore after booting : > >> root@bbb:~ # kldstat > >> Id Refs Address Size Name > >> 1 1 0xc0000000 d23a8c kernel > >> > >> I don't think it has to do with the switch to GENERICSD, there is (at > >> least shouldn't be) any difference between the old BBB image and the > >> GENERICSD one. > > Yes, this might well be a coincidence. I do neither have the last BBB specific snapshot nor the first GENERICSD one for testing these against each other. > > > Just did a test on my OrangePi One (Allwinner H3 armv7 with 512MB of > > RAM) and this is the same. > > The problem seems to be module dependancy, loader only loads > > if_rtnw_usb but doing a kldload also brings wlan.ko and rtwn.ko > > I can confirm this. And in addition loading the if_rtwn_usb.ko module and its dependcies manually also takes now significantly longer compared to a manual load on the BBB specific 13-CURRENT from November. Perhaps something has been changed in the dependency resolver. > Fixed in 0f2434ea000e Thanks for reporting. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Jan 17 17:40:10 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 88C064D159E; Sun, 17 Jan 2021 17:40:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJhyK4pvnz3lQY; Sun, 17 Jan 2021 17:40:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 10HHe6Zg030969 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 17 Jan 2021 09:40:07 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 10HHe6C5030968; Sun, 17 Jan 2021 09:40:06 -0800 (PST) (envelope-from fbsd) Date: Sun, 17 Jan 2021 09:40:06 -0800 From: bob prohaska To: bob prohaska Cc: Current FreeBSD , freebsd-arm@freebsd.org Subject: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld Message-ID: <20210117174006.GA30728@www.zefox.net> References: <20210116043740.GA19523@www.zefox.net> <20210116155538.GA24259@www.zefox.net> <20210116220334.GA26756@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DJhyK4pvnz3lQY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [-1.06 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.963]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-arm]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 17:40:10 -0000 On Sat, Jan 16, 2021 at 03:04:04PM -0800, Mark Millard wrote: > > Other than -j1 style builds (or equivalent), one pretty much > always needs to go looking around for a non-panic failure. It > is uncommon for all the material to be together in the build > log in such contexts. Running make cleandir twice and restarting -j4 buildworld brought the process full circle: A silent hang, no debugger response, no console warnings. That's what sent me down the rabbit hole of make without clean, which worked at least once... The residue of the top screen shows last pid: 63377; load averages: 4.29, 4.18, 4.15 up 1+07:11:07 04:46:46 60 processes: 5 running, 55 sleeping CPU: 70.7% user, 0.0% nice, 26.5% system, 2.8% interrupt, 0.0% idle Mem: 631M Active, 4932K Inact, 92M Laundry, 166M Wired, 98M Buf, 18M Free Swap: 2048M Total, 119M Used, 1928M Free, 5% Inuse, 16K In, 3180K Out packet_write_wait: Connection to 50.1.20.26 port 22: Broken pipe bob@raspberrypi:~ $ ssh www.zefox.com RES STATE C TIME WCPU COMMAND ssh: connect to host www.zefox.com port 22: Connection timed out86.17% c++ bob@raspberrypi:~ $ 1 99 0 277M 231M RUN 0 3:26 75.00% c++ 63245 bob 1 99 0 219M 173M CPU0 0 2:10 73.12% c++ 62690 bob 1 98 0 354M 234M RUN 3 9:42 47.06% c++ 63377 bob 1 30 0 5856K 2808K nanslp 0 0:00 3.13% gstat 38283 bob 1 24 0 5208K 608K wait 2 2:00 0.61% sh 995 bob 1 20 0 6668K 1184K CPU3 3 8:46 0.47% top 990 bob 1 20 0 12M 1060K select 2 0:48 0.05% sshd .... [apologies for typing over the remnants] I've put copies of the build and swap logs at http://www.zefox.net/~fbsd/rpi2/buildworld/ The last vmstat entry (10 second repeat time) reports: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr da0 sd0 in sy cs us sy id 4 0 14 969160 91960 685 2 2 1 707 304 0 0 11418 692 1273 45 5 50 Does that point to the memory exhaustion suggested earlier in the thread? At this point /boot/loader.conf contains vm.pfault_oom_attempts="-1", but that's a relic of long-ago attempts to use USB flash for root and swap. Might removing it stimulate more warning messages? Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Sun Jan 17 20:30:58 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A67394D6F9D for ; Sun, 17 Jan 2021 20:30:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJmlP3G4mz4SlJ for ; Sun, 17 Jan 2021 20:30:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610915456; bh=Cd2HaY4Pnd1u+IWNtkuP7CHU02P5U0AOnKgCrsv2vI5=; h=Subject:From:Date:To:From:Subject:Reply-To; b=NjF+cjhm5hfrVcsqBj0yRBMSaJq23g5QVpCcqboDwl/Fp2BY8XQag9oT8j3jxicJQmcuVln9lWBX1L9RvqF5lvmyaLoNtmPikuzyLFH+XuHgh/0/RZLubNFs7z17QrC3wi7G0as81pZ0KuAohBwuHICVlGwXETpSlr1+JQED9W4I/iY4yQVyddzroV17ZruX517gGcevXPqK3LWgSZLoirJMkFHK5K9pI+db9V8rM/H6AsVTkx3k1yJXRAx01NH2IRErAvnnOI6z4a4zBeK8jsYyGI1795ZJZYrFbjh1aSWpVqE5Afr9DGePDsDN8R8CPFb6ojlfOiAvErBmePUzsA== X-YMail-OSG: ixDoYs4VM1nPq2scFH9FyUhGO52i17OD8nKkE52E3SaWai2JoSAXdagKcXvNz2y UgbRDViElKbOFzO9lsxI0ubPDIc1gwCmZfb8t6aiDYK_n5jW3dvaV.Qe4iE_QHTDD2dIpB4pAC4Z WOoEIQUV_a_KfBu_WRfbeIEvTD9MWWwZy5n0KpNl6R2yqSYX50rsCcyR7W.ehi9EIKE6CQR9BSK4 fCqGCOZNgAQMMnh6MkIQuPNk5HRWypMHgcBmdAyCyRa8PSPgguSzil0WU7RGJ01kYXbGpMTbyJsA a.Ed0lNZzshKBWzNZA5hMKHbC8.ce1MgEatz9BdVEa4yawMgsVyWYXgNrGthQem7T_gnQ_Wqmfw5 dvscH8cUwvU_fXH8iyFSZbWL3UyuvTpRAmHnLE2onjOnjpm2OhPVksk..rZ6V5KzvrBVqVVyHl96 yHg5MovSVN.Lo9Ds2VX2H_RrRtJwGXASqtCCllpCuA.gmr5c.7eXY5chAFFSbNA8oxT2Z8rHGATC pxIMoDMra19zEspdFsT91fOmJUs1gpFGcyZrmLmlUmdazKWAurjVyZT1OzskVPk7nKMkydD3jGu8 1cwToJQgfpBoRsdaCDJ6bCfx0vQ3lVDgRC9krQR5VCSDgIcMONHrxHxSnIzS2AWYdpGq1gn3K.Oy G5jVgDwakBy3m3xZS9hidM2m3jzsJai3wsJz9eRSuQApJlnLa1EiBqiSGhHhRZd2sItn736VJyuY s7niPlhqfGZNB7Ovk93DUEG_mu7WBCDzO86R2BK_336QkIBORyjrLHcwg_.Pw.es9JOVsmSRofU0 eM6rkfX5bccjX8go3qbNx6WC_QfBMjvDLLkF9l.nrKxAfadJZsgcbxmLG5aKqrgweO99vU16Hrcu 6d_GH2W.Pd9_G6IPFVrvp9szwEWewiy8.TWk3ARh9X_jfkUUgczpZge8ytgRyB1P9cNXG9PYMCzI xUiD.FEYhCbjporqfQBeTHRt08CODqbFY0yU77IfN.8J5W0oEc0ytZ5EDCJZMzGki7h_t1bpcOS0 RoDkZpjRJJzhVCa2aY_XdlSN985KaNRrm31hmt0doHyRXBge9QYu4Ig5vU7fbi7cSEu8GyK1VC6X 4uuxNaaJKMEwX5lXiJoZiBc0fsBsWyFhKLd79ZPt8JIlQE7noSruqO3DEPiAvennfFlNPjjL.b8. hjLcnXEssS_zigoatzaXDNVGaWWKjAoPyJ5nca7pBy6HCC96MQUsfrrY6sQN2bwVcI0.HUku394f KzpnNbkOfPkv32hNiKYU3TmC2AbZH3TSML6LatCyOQ_9sJAJsIcff8oO.MnzOCIfvmqyJALCg6Cr QlxXgxK1e3_AN6qfjiV.MkjBfUCj0dUvq5xNQD7Ei3A.4b2yNr49r3TtFtpsRHb6TIJQjCn0M151 9512gIbUCF6C8BkBUOF_pEfcqanyG1_9cpEvwpBesMnDDsrZ_qp8mxygFgAwCCm0C0wjsCqGhbny r2bnB6Lwe9kbduznvoIYsMvU9pUVYwTngP4UoWtlnkyQF5VA.kiVbfVSA5mt8uwZbuRExNKb9ggi 0Qn1M04M.KL2cq.ciANQSCxJ1rJ1MSH5Q0MuOBtcsq.PO7e8nHZMWrBnPs7aiCyYQ5VYMmpOGvyL pqIqRl.8YAkf_vKHuaxFbsNAMJjK1k0Utc0VtiqFyWoLlZqlFGAAspEwbrjtXLxmcCPfQQnVlQiA IWpdLDKVwJHnFkINlwu825VeTJKxVghuxcnz2jkEI0q23d_4usU5QWv19s9cs2hBufYfzXbbMuZ2 FUagyMWhVUUvTBCwANyPQZreE99kwDRDVRatm8gxhZ1l5Bcb3iQWDAnYeITvoYmXNVhszodbIzDZ blLUjh..U5XR602sn_SH9Au4saZJHogxTr74U1h2V6ilUDZF2gpz1DDrQlrMkfSLitqv4GRj1cU0 DV.Z3m57LwSz_gIpgvcyJxPduY0.jcpOEupsT7jWzIb.Qd9Pw5DD_G3GyTC4rljt7s7VdjZ_4XVX zTzzilVPojnr7nzBolOmdyzXdohVq0SDG54nCmskjl.VgWM0_c5zJXmD5COScUL0YYmBwco4VOQ_ HcQlHMoMGtRyUYerqDPb0xpEqzQ8OOF_XKRfEKFd.rvA0vFWtfCN9PCEbfFNrXlCiNZUPGXhklTi 8qAy7HeSnjdkI4j80Nlcd5CVMBrI8LKJ1h5TDR2m5kWtpLJtFkpXcMYcbg3I0va6ma4vZG0OKrMl OYE0aRgAScyIeEbcEpHA8NkIEaglp80Lzhlzk469BAKrkf94QTSRLPcDsBj4voYUwvycsgg_1D3o _AD96FmcQ0zKPoZfud7XSgZsonIDNk72qR9kBIA1AvKk7.f6TmIyJPSTAiMRvCoS7rYgU0nj6nPi 2VL6oVwp.fXehH3UEmjuwEzqoGnIvQhGcDvP1AiG4b6_YOQqJwYGAC_o70dSciHWG8F93rCAY0cB 3zaifIrN_ecLvAr8TaozHAxSnEnOFfacpLZMdf7fUW9PpJuv3AJ_vhgd.8DVGYZZ641ugUQyfakq Gy2c0vXxZSeUkQbBP9SdZcLsH3lDVzgRTDQWp9sx5P72QlHt_NktdCDU6SXiA27L7qUaNOG4BmHL qqg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sun, 17 Jan 2021 20:30:56 +0000 Received: by smtp409.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ae0a4229a77b65e188d5e772bbde91a7; Sun, 17 Jan 2021 20:30:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <20210117174006.GA30728@www.zefox.net> Date: Sun, 17 Jan 2021 12:30:51 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> References: <20210116043740.GA19523@www.zefox.net> <20210116155538.GA24259@www.zefox.net> <20210116220334.GA26756@www.zefox.net> <20210117174006.GA30728@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DJmlP3G4mz4SlJ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 20:30:58 -0000 On 2021-Jan-17, at 09:40, bob prohaska wrote: > On Sat, Jan 16, 2021 at 03:04:04PM -0800, Mark Millard wrote: >>=20 >> Other than -j1 style builds (or equivalent), one pretty much >> always needs to go looking around for a non-panic failure. It >> is uncommon for all the material to be together in the build >> log in such contexts. >=20 > Running make cleandir twice and restarting -j4 buildworld brought > the process full circle: A silent hang, no debugger response, no > console warnings. That's what sent me down the rabbit hole of make > without clean, which worked at least once... Unfortunately, such a hang tends to mean that log files and such were not completely written out to media. We do not get to see evidence of the actual failure time frame, just somewhat before. (compiler/linker output and such can have the same issues of ending up with incomplete updates.) So, pretty much my notes are unlikely to be strongly tied to any solid evidence: more like alternatives to possibly explore that could be far off the mark. It is not clear if you were using: LDFLAGS.lld+=3D -Wl,--threads=3D1 or some such to limit the multi-thread linking and its memory. I'll note that if -j4 gets 4 links running in parallel it used to be each could have something like 5 threads active on a 4 core machine, so 20 or so threads. (I've not checked llvm11's lld behavior. It might avoid such for defaults.) You have not reported any testing of -j2 or -j3 so far, just -j4 . (Another way of limiting memory use, power use, temperature, etc. .) You have not reported if your boot complained about the swap space size or if you have adjusted related settings to make non-default tradeoffs for swap amanagment for these specific tests. I recommend not tailoring and using a swap size total that is somewhat under what starts to complain when there is no tailoring. > The residue of the top screen shows >=20 > last pid: 63377; load averages: 4.29, 4.18, 4.15 = up 1+07:11:07 04:46:46 > 60 processes: 5 running, 55 sleeping > CPU: 70.7% user, 0.0% nice, 26.5% system, 2.8% interrupt, 0.0% idle > Mem: 631M Active, 4932K Inact, 92M Laundry, 166M Wired, 98M Buf, 18M = Free > Swap: 2048M Total, 119M Used, 1928M Free, 5% Inuse, 16K In, 3180K Out > packet_write_wait: Connection to 50.1.20.26 port 22: Broken pipe > bob@raspberrypi:~ $ ssh www.zefox.com RES STATE C TIME WCPU = COMMAND > ssh: connect to host www.zefox.com port 22: Connection timed out86.17% = c++ > bob@raspberrypi:~ $ 1 99 0 277M 231M RUN 0 3:26 75.00% = c++ > 63245 bob 1 99 0 219M 173M CPU0 0 2:10 73.12% = c++ > 62690 bob 1 98 0 354M 234M RUN 3 9:42 47.06% = c++ > 63377 bob 1 30 0 5856K 2808K nanslp 0 0:00 3.13% = gstat > 38283 bob 1 24 0 5208K 608K wait 2 2:00 0.61% = sh > 995 bob 1 20 0 6668K 1184K CPU3 3 8:46 0.47% = top > 990 bob 1 20 0 12M 1060K select 2 0:48 0.05% = sshd > .... This does not look like ld was in use as of the last top display update's content. But the time between reasonable display updates is fairly long relative to CPU activity so it is only suggestive. > [apologies for typing over the remnants] >=20 > I've put copies of the build and swap logs at >=20 > http://www.zefox.net/~fbsd/rpi2/buildworld/ >=20 > The last vmstat entry (10 second repeat time) reports: > procs memory page disks faults = cpu > r b w avm fre flt re pi po fr sr da0 sd0 in sy = cs us sy id > 4 0 14 969160 91960 685 2 2 1 707 304 0 0 11418 = 692 1273 45 5 50 >=20 > Does that point to the memory exhaustion suggested earlier in the = thread? > At this point /boot/loader.conf contains vm.pfault_oom_attempts=3D"-1", = but=20 > that's a relic of long-ago attempts to use USB flash for root and = swap. > Might removing it stimulate more warning messages? >=20 vm.pfault_oom_attempts=3D"-1" should only be used in contexts where running out of swap will not happen. Otherwise a deadlocked system can result if it does run out of swap. (Run-out has more senses the just the swap partition being fully used: other internal resources for keeping track of the swap can run into its limits.) I've no evidence that the -1 was actually a problem. I do not find any 1000+ ms/w or ms/r figures in swapscript.log . I found 3 examples of a little under 405 (on sdda0*), 3 between 340 and 345 (da0*), 4 in the 200s (da0*), under 60 in the 100s (da0*). It does not look to me like the recorded part had problems with the long latencies that you used to have happen. So I've not found any specific evidence about what led to the hangup. So my earlier questions/suggestions are basically arbitrary and I would not know what to do with any answers to the questions. The only notes that are fairly solid are about the hangup leading to there being some files that were likely incompletely updated (logs, compiler output files, etc.). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Jan 17 21:49:10 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6760E4D92B2 for ; Sun, 17 Jan 2021 21:49:10 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJpTd34Ywz4ZBN for ; Sun, 17 Jan 2021 21:49:08 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1610920146; s=strato-dkim-0002; d=obsigna.com; h=References:To:Cc:In-Reply-To:Date:Subject:Message-Id:From:From: Subject:Sender; bh=T22rEl6zv2ZJbejdVJ42xwmRxMvCAk5ZF+Zc3BenOY0=; b=F5six77l44NsBMoai3rZJpbkh9uPfutFKetH6Ea1C/2+cvlogcnBBv6ZlSeSF85NQz tCyjrmWgokO/FhQZnnBYZHTpuAeNLQElGZy5piGIA14Ty34CDRcV4sqouxja7P+CuJ4e ejOuVg0n4WOTCyUWBR3P9n9QqWvnq2trZXqsHIlwxBiQ/lFkw0FT/FyiKM9eJdLa933q VL7RPAHrBJat7/tuy+k8CkzK8Oz1mXWjAgRjNCDF6+1nkNqpuU0tsT99b0Q3OWqpqcy1 e8r8RTF2NkP2qyfL6l/emtu6SH7Asab2V7ZqtnvapNAdRVZgFNOW/m5sX+vjLUAvPF8c 8SjA== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio0dVVInWnas+zpAhAiA/W" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 47.12.1 DYNA|AUTH) with ESMTPSA id d0872bx0HLn4iPZ (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 17 Jan 2021 22:49:04 +0100 (CET) Received: from rolf-mini.obsigna.com (rolf-mini.obsigna.com [192.168.222.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id ACDE11350F946; Sun, 17 Jan 2021 18:49:01 -0300 (-03) From: "Dr. Rolf Jansen" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: GENERICSD snapshot on a BBB has issues with loading the if_rtwn_usb module Date: Sun, 17 Jan 2021 18:49:01 -0300 In-Reply-To: <20210117174539.43b55379e6a37881589616a8@bidouilliste.com> Cc: freebsd-arm@freebsd.org To: Emmanuel Vadot References: <47700631-2D94-4BA8-9707-9ADD70C99600@obsigna.com> <20210116184333.f91594f9c3505d2c588d9634@bidouilliste.com> <20210116184833.1a3182a20a2b6c727b64bb59@bidouilliste.com> <06F689CA-B781-4CEB-8F8A-B00FAC684DD3@obsigna.com> <20210117174539.43b55379e6a37881589616a8@bidouilliste.com> X-Mailer: Apple Mail (2.3445.104.15) X-Rspamd-Queue-Id: 4DJpTd34Ywz4ZBN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=obsigna.com header.s=strato-dkim-0002 header.b=F5six77l; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@obsigna.com designates 85.215.255.20 as permitted sender) smtp.mailfrom=freebsd-rj@obsigna.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24]; RWL_MAILSPIKE_GOOD(0.00)[85.215.255.20:from]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[obsigna.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[85.215.255.20:from]; ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[obsigna.com:s=strato-dkim-0002]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[obsigna.com]; SPAMHAUS_ZRD(0.00)[85.215.255.20:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[85.215.255.20:from]; FROM_NAME_HAS_TITLE(1.00)[dr]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 21:49:10 -0000 > Am 17.01.2021 um 13:45 schrieb Emmanuel Vadot : >=20 > On Sat, 16 Jan 2021 15:11:28 -0300 > "Dr. Rolf Jansen" > wrote: >=20 >>> Am 16.01.2021 um 14:48 schrieb Emmanuel Vadot >: >>>=20 >>> On Sat, 16 Jan 2021 18:43:33 +0100 >>> Emmanuel Vadot = >> wrote: >>>=20 >>>> On Sat, 16 Jan 2021 14:08:58 -0300 >>>> "Dr. Rolf Jansen" wrote: >>>>=20 >>>>> I updated one of my BBB from an older 13-CURRENT (July 2020) to = the latest 13-ALPHA1 snapshot from Jan, 14th ? = GENERICSD-20210114-7ae27c2d6c4-255938. >>>>>=20 >>>>> I had successfully employed an USB-WLAN dongle based on the = RTL8188eu chipset. I only added the following into /boot/loader.conf: >>>>>=20 >>>>> if_rtwn_usb_load=3D"YES" >>>>>=20 >>>>> By that all dependend modules were loaded automatically in a snap. = With ALPHA1 this doesn?t work anymore. After hours of troubleshooting, I = got it working by adding the following into /etc/rc.conf: >>>>>=20 >>>>> kld_list=3D"if_rtwn_usb" >>>>>=20 >>>>> The "Loading kernel modules:" takes apprx. 4 seconds, however, = then the USB-WLAN device is enumerated correctly and it is ready to use. = This makes me think that this uncommon huge delay is the culprit. I = checked this with some snapshot thats I had installed already. The issue = seems to have been introduced together with the switch to GENERICSD. A = GENERICSD 13-CURRENT from end of December showed this issue already, = while a BBB-specific snapshot (from November 2020) that I had installed = on another BBB works as before by loading the modules in = /boot/loader.conf. >>>>>=20 >>>>> I don't mind to load the modules by the way of the kld_list = directive in /etc/rc.conf. However, the unusual long duration of loading = the module and its dependencies might be an indication for a more = fundamental issue. >>>>>=20 >>>>> Please feel free to ask me for doing more tests.=20 >>>>>=20 >>>>> Best regards >>>>>=20 >>>>> Rolf >>>>=20 >>>> I can reproduce that on my netbooted BBB. >>>> The module is correctly loaded : >>>>=20 >>>> Loading >>>> kernel... /boot/kernel/kernel text=3D0x1b4 text=3D0x68d638 = text=3D0x1c84f0 >>>> data=3D0xb4070 data=3D0x0+0x258000 syms=3D[0x4+0xa5ab0+0x4+0x119fd4] = Loading >>>> configured modules... /boot/kernel/if_rtwn_usb.ko text=3D0xb960 >>>> text=3D0x62c0 data=3D0x2cc+0x3b syms=3D[0x4+0x3570+0x4+0x293f] = /boot/entropy >>>> size=3D0x1000 /etc/hostid >>>> size=3D0x25 Using DTB provided by EFI at >>>> 0x87f00000. Kernel entry at >>>> 0x96e00200... Kernel args: >>>> (null) = =20 >>>> ---<>--- = =20 >>>>=20 >>>> But it isn't loaded anymore after booting : >>>> root@bbb:~ # kldstat=20 >>>> Id Refs Address Size Name >>>> 1 1 0xc0000000 d23a8c kernel >>>>=20 >>>> I don't think it has to do with the switch to GENERICSD, there is = (at >>>> least shouldn't be) any difference between the old BBB image and = the >>>> GENERICSD one. >>=20 >> Yes, this might well be a coincidence. I do neither have the last BBB = specific snapshot nor the first GENERICSD one for testing these against = each other. >>=20 >>> Just did a test on my OrangePi One (Allwinner H3 armv7 with 512MB of >>> RAM) and this is the same. >>> The problem seems to be module dependancy, loader only loads >>> if_rtnw_usb but doing a kldload also brings wlan.ko and rtwn.ko >>=20 >> I can confirm this. And in addition loading the if_rtwn_usb.ko module = and its dependcies manually also takes now significantly longer compared = to a manual load on the BBB specific 13-CURRENT from November. Perhaps = something has been changed in the dependency resolver. >>=20 >=20 > Fixed in 0f2434ea000e >=20 > Thanks for reporting. Unfortunately, this did not resolve the issue. I updated my working copy = with git pull and verified that your changes made it into my source = tree. Then I built a new kernel and replaced the original ALPHA1 kernel = from 2021-01-14 by this new one. The rtwn-modules are still not loaded = by the if_rtwn_usb_load=3D"YES" directive in /boot/loader.conf. Best regards Rolf= From owner-freebsd-arm@freebsd.org Sun Jan 17 21:55:44 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A9EC64D9A09 for ; Sun, 17 Jan 2021 21:55:44 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJpdC4twDz4Zms for ; Sun, 17 Jan 2021 21:55:43 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1610920539; 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=fOb1qRFmk3ReiiKHHFHDkWxzQOxaw6xBtdLeIapMg9I=; b=OLvwtZKTKOH4kkSbWvDlagbaLuCFg3d/VFyleG1Q7EuzZa5jealp9QtYWnZFRl6zzuB6M1 5hJKVoTXG2fa18GLT8SUOeurUG1bhP/uhjejiUs2EyosRXXTPxiYKd3CRGs5g/u7U3Wrmb 8JZvJSMLtq9JN0/aP7wMQncrNfdKsOk= Received: from skull.home.blih.net (lfbn-idf2-1-745-114.w86-247.abo.wanadoo.fr [86.247.192.114]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 84448748 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 17 Jan 2021 21:55:39 +0000 (UTC) Date: Sun, 17 Jan 2021 22:55:39 +0100 From: Emmanuel Vadot To: "Dr. Rolf Jansen" Cc: freebsd-arm@freebsd.org Subject: Re: GENERICSD snapshot on a BBB has issues with loading the if_rtwn_usb module Message-Id: <20210117225539.c113796159735c5a3950c774@bidouilliste.com> In-Reply-To: References: <47700631-2D94-4BA8-9707-9ADD70C99600@obsigna.com> <20210116184333.f91594f9c3505d2c588d9634@bidouilliste.com> <20210116184833.1a3182a20a2b6c727b64bb59@bidouilliste.com> <06F689CA-B781-4CEB-8F8A-B00FAC684DD3@obsigna.com> <20210117174539.43b55379e6a37881589616a8@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DJpdC4twDz4Zms X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=OLvwtZKT; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-1.84 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.66)[0.664]; SPAMHAUS_ZRD(0.00)[212.83.155.74:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.83.155.74:from]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 21:55:44 -0000 On Sun, 17 Jan 2021 18:49:01 -0300 "Dr. Rolf Jansen" wrote: > > Am 17.01.2021 um 13:45 schrieb Emmanuel Vadot : > > > > On Sat, 16 Jan 2021 15:11:28 -0300 > > "Dr. Rolf Jansen" > wrote: > > > >>> Am 16.01.2021 um 14:48 schrieb Emmanuel Vadot >: > >>> > >>> On Sat, 16 Jan 2021 18:43:33 +0100 > >>> Emmanuel Vadot >> wrote: > >>> > >>>> On Sat, 16 Jan 2021 14:08:58 -0300 > >>>> "Dr. Rolf Jansen" wrote: > >>>> > >>>>> I updated one of my BBB from an older 13-CURRENT (July 2020) to the latest 13-ALPHA1 snapshot from Jan, 14th ? GENERICSD-20210114-7ae27c2d6c4-255938. > >>>>> > >>>>> I had successfully employed an USB-WLAN dongle based on the RTL8188eu chipset. I only added the following into /boot/loader.conf: > >>>>> > >>>>> if_rtwn_usb_load="YES" > >>>>> > >>>>> By that all dependend modules were loaded automatically in a snap. With ALPHA1 this doesn?t work anymore. After hours of troubleshooting, I got it working by adding the following into /etc/rc.conf: > >>>>> > >>>>> kld_list="if_rtwn_usb" > >>>>> > >>>>> The "Loading kernel modules:" takes apprx. 4 seconds, however, then the USB-WLAN device is enumerated correctly and it is ready to use. This makes me think that this uncommon huge delay is the culprit. I checked this with some snapshot thats I had installed already. The issue seems to have been introduced together with the switch to GENERICSD. A GENERICSD 13-CURRENT from end of December showed this issue already, while a BBB-specific snapshot (from November 2020) that I had installed on another BBB works as before by loading the modules in /boot/loader.conf. > >>>>> > >>>>> I don't mind to load the modules by the way of the kld_list directive in /etc/rc.conf. However, the unusual long duration of loading the module and its dependencies might be an indication for a more fundamental issue. > >>>>> > >>>>> Please feel free to ask me for doing more tests. > >>>>> > >>>>> Best regards > >>>>> > >>>>> Rolf > >>>> > >>>> I can reproduce that on my netbooted BBB. > >>>> The module is correctly loaded : > >>>> > >>>> Loading > >>>> kernel... /boot/kernel/kernel text=0x1b4 text=0x68d638 text=0x1c84f0 > >>>> data=0xb4070 data=0x0+0x258000 syms=[0x4+0xa5ab0+0x4+0x119fd4] Loading > >>>> configured modules... /boot/kernel/if_rtwn_usb.ko text=0xb960 > >>>> text=0x62c0 data=0x2cc+0x3b syms=[0x4+0x3570+0x4+0x293f] /boot/entropy > >>>> size=0x1000 /etc/hostid > >>>> size=0x25 Using DTB provided by EFI at > >>>> 0x87f00000. Kernel entry at > >>>> 0x96e00200... Kernel args: > >>>> (null) > >>>> ---<>--- > >>>> > >>>> But it isn't loaded anymore after booting : > >>>> root@bbb:~ # kldstat > >>>> Id Refs Address Size Name > >>>> 1 1 0xc0000000 d23a8c kernel > >>>> > >>>> I don't think it has to do with the switch to GENERICSD, there is (at > >>>> least shouldn't be) any difference between the old BBB image and the > >>>> GENERICSD one. > >> > >> Yes, this might well be a coincidence. I do neither have the last BBB specific snapshot nor the first GENERICSD one for testing these against each other. > >> > >>> Just did a test on my OrangePi One (Allwinner H3 armv7 with 512MB of > >>> RAM) and this is the same. > >>> The problem seems to be module dependancy, loader only loads > >>> if_rtnw_usb but doing a kldload also brings wlan.ko and rtwn.ko > >> > >> I can confirm this. And in addition loading the if_rtwn_usb.ko module and its dependcies manually also takes now significantly longer compared to a manual load on the BBB specific 13-CURRENT from November. Perhaps something has been changed in the dependency resolver. > >> > > > > Fixed in 0f2434ea000e > > > > Thanks for reporting. > > Unfortunately, this did not resolve the issue. I updated my working copy with git pull and verified that your changes made it into my source tree. Then I built a new kernel and replaced the original ALPHA1 kernel from 2021-01-14 by this new one. The rtwn-modules are still not loaded by the if_rtwn_usb_load="YES" directive in /boot/loader.conf. > > Best regards > > Rolf You need to update loader.efi on the ESP partition. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Jan 17 22:01:32 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8C56C4D99AF for ; Sun, 17 Jan 2021 22:01:32 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.221]) (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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJplv0jdWz4Zxj for ; Sun, 17 Jan 2021 22:01:30 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1610920888; s=strato-dkim-0002; d=obsigna.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:From: Subject:Sender; bh=Q2yDIHc9RKfpgVRjfTQI//7gehGppVKNmkIfuvBjSZI=; b=EfqCG1oVTcEWaaVII5HBNzsr253fK5+RVUGebNJZTTqZ/Yg28CEmcscfkrV04GISzN FlFqpmucNpdxKwDiOBLElcKzL5qUg+6XXBeU+XEN3Y3F3yxc5VB8EptfPFZEQ3hzNf9E PJe4C7y6cDdu9GOOKZ2VHS10xPHjRg9tonfk06hlbrL0FKqQ3S7qKlobVUMy+eAsjRmV UvuQj3KcwBSjws72Exe66KXc1NdCryxY34Pa3GqCvBvp1ixP627bg7keJ1Bp5v01/EvN ntehqiecbY3qqmsMT5K/IxRQalQldK8Aghycf3Wnudy70N9PJLH/ehRbP7PIpuo7wOxY nNkA== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio0dVVInWnas+zpAhAiA/W" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 47.12.1 DYNA|AUTH) with ESMTPSA id d0872bx0HM1RiQF (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 17 Jan 2021 23:01:27 +0100 (CET) Received: from rolf-mini.obsigna.com (rolf-mini.obsigna.com [192.168.222.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id EBD031350F946; Sun, 17 Jan 2021 19:01:24 -0300 (-03) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: GENERICSD snapshot on a BBB has issues with loading the if_rtwn_usb module From: "Dr. Rolf Jansen" In-Reply-To: <20210117225539.c113796159735c5a3950c774@bidouilliste.com> Date: Sun, 17 Jan 2021 19:01:24 -0300 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <03F9A3D3-0A2B-4B09-9C8D-AAAF761C0F4C@obsigna.com> References: <47700631-2D94-4BA8-9707-9ADD70C99600@obsigna.com> <20210116184333.f91594f9c3505d2c588d9634@bidouilliste.com> <20210116184833.1a3182a20a2b6c727b64bb59@bidouilliste.com> <06F689CA-B781-4CEB-8F8A-B00FAC684DD3@obsigna.com> <20210117174539.43b55379e6a37881589616a8@bidouilliste.com> <20210117225539.c113796159735c5a3950c774@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.104.15) X-Rspamd-Queue-Id: 4DJplv0jdWz4Zxj X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=obsigna.com header.s=strato-dkim-0002 header.b=EfqCG1oV; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@obsigna.com designates 81.169.146.221 as permitted sender) smtp.mailfrom=freebsd-rj@obsigna.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[obsigna.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[81.169.146.221:from]; ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[obsigna.com:s=strato-dkim-0002]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[obsigna.com]; SPAMHAUS_ZRD(0.00)[81.169.146.221:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[81.169.146.221:from]; FROM_NAME_HAS_TITLE(1.00)[dr]; RWL_MAILSPIKE_POSSIBLE(0.00)[81.169.146.221:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 22:01:32 -0000 > Am 17.01.2021 um 18:55 schrieb Emmanuel Vadot : >=20 > On Sun, 17 Jan 2021 18:49:01 -0300 > "Dr. Rolf Jansen" wrote: >=20 >>> Am 17.01.2021 um 13:45 schrieb Emmanuel Vadot = : >>>=20 >>> On Sat, 16 Jan 2021 15:11:28 -0300 >>> "Dr. Rolf Jansen" > wrote: >>>=20 >>>>> Am 16.01.2021 um 14:48 schrieb Emmanuel Vadot = >: >>>>>=20 >>>>> On Sat, 16 Jan 2021 18:43:33 +0100 >>>>> Emmanuel Vadot >> wrote: >>>>>=20 >>>>>> On Sat, 16 Jan 2021 14:08:58 -0300 >>>>>> "Dr. Rolf Jansen" wrote: >>>>>>=20 >>>>>>> I updated one of my BBB from an older 13-CURRENT (July 2020) to = the latest 13-ALPHA1 snapshot from Jan, 14th ? = GENERICSD-20210114-7ae27c2d6c4-255938. >>>>>>>=20 >>>>>>> I had successfully employed an USB-WLAN dongle based on the = RTL8188eu chipset. I only added the following into /boot/loader.conf: >>>>>>>=20 >>>>>>> if_rtwn_usb_load=3D"YES" >>>>>>>=20 >>>>>>> By that all dependend modules were loaded automatically in a = snap. With ALPHA1 this doesn?t work anymore. After hours of = troubleshooting, I got it working by adding the following into = /etc/rc.conf: >>>>>>>=20 >>>>>>> kld_list=3D"if_rtwn_usb" >>>>>>>=20 >>>>>>> The "Loading kernel modules:" takes apprx. 4 seconds, however, = then the USB-WLAN device is enumerated correctly and it is ready to use. = This makes me think that this uncommon huge delay is the culprit. I = checked this with some snapshot thats I had installed already. The issue = seems to have been introduced together with the switch to GENERICSD. A = GENERICSD 13-CURRENT from end of December showed this issue already, = while a BBB-specific snapshot (from November 2020) that I had installed = on another BBB works as before by loading the modules in = /boot/loader.conf. >>>>>>>=20 >>>>>>> I don't mind to load the modules by the way of the kld_list = directive in /etc/rc.conf. However, the unusual long duration of loading = the module and its dependencies might be an indication for a more = fundamental issue. >>>>>>>=20 >>>>>>> Please feel free to ask me for doing more tests.=20 >>>>>>>=20 >>>>>>> Best regards >>>>>>>=20 >>>>>>> Rolf >>>>>>=20 >>>>>> I can reproduce that on my netbooted BBB. >>>>>> The module is correctly loaded : >>>>>>=20 >>>>>> Loading >>>>>> kernel... /boot/kernel/kernel text=3D0x1b4 text=3D0x68d638 = text=3D0x1c84f0 >>>>>> data=3D0xb4070 data=3D0x0+0x258000 = syms=3D[0x4+0xa5ab0+0x4+0x119fd4] Loading >>>>>> configured modules... /boot/kernel/if_rtwn_usb.ko text=3D0xb960 >>>>>> text=3D0x62c0 data=3D0x2cc+0x3b syms=3D[0x4+0x3570+0x4+0x293f] = /boot/entropy >>>>>> size=3D0x1000 /etc/hostid >>>>>> size=3D0x25 Using DTB provided by EFI at >>>>>> 0x87f00000. Kernel entry at >>>>>> 0x96e00200... Kernel args: >>>>>> (null) = =20 >>>>>> ---<>--- = =20 >>>>>>=20 >>>>>> But it isn't loaded anymore after booting : >>>>>> root@bbb:~ # kldstat=20 >>>>>> Id Refs Address Size Name >>>>>> 1 1 0xc0000000 d23a8c kernel >>>>>>=20 >>>>>> I don't think it has to do with the switch to GENERICSD, there is = (at >>>>>> least shouldn't be) any difference between the old BBB image and = the >>>>>> GENERICSD one. >>>>=20 >>>> Yes, this might well be a coincidence. I do neither have the last = BBB specific snapshot nor the first GENERICSD one for testing these = against each other. >>>>=20 >>>>> Just did a test on my OrangePi One (Allwinner H3 armv7 with 512MB = of >>>>> RAM) and this is the same. >>>>> The problem seems to be module dependancy, loader only loads >>>>> if_rtnw_usb but doing a kldload also brings wlan.ko and rtwn.ko >>>>=20 >>>> I can confirm this. And in addition loading the if_rtwn_usb.ko = module and its dependcies manually also takes now significantly longer = compared to a manual load on the BBB specific 13-CURRENT from November. = Perhaps something has been changed in the dependency resolver. >>>>=20 >>>=20 >>> Fixed in 0f2434ea000e >>>=20 >>> Thanks for reporting. >>=20 >> Unfortunately, this did not resolve the issue. I updated my working = copy with git pull and verified that your changes made it into my source = tree. Then I built a new kernel and replaced the original ALPHA1 kernel = from 2021-01-14 by this new one. The rtwn-modules are still not loaded = by the if_rtwn_usb_load=3D"YES" directive in /boot/loader.conf. >>=20 >> Best regards >>=20 >> Rolf >=20 > You need to update loader.efi on the ESP partition. Please excuse my ignorance. Do I need to build world for this? Then = where is the newly build loader.efi? Best regards Rolf From owner-freebsd-arm@freebsd.org Mon Jan 18 01:50:09 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4CE654DDDF2; Mon, 18 Jan 2021 01:50:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJvqh0Lzhz4mQy; Mon, 18 Jan 2021 01:50:07 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 10I1oA88032823 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 17 Jan 2021 17:50:10 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 10I1oApG032822; Sun, 17 Jan 2021 17:50:10 -0800 (PST) (envelope-from fbsd) Date: Sun, 17 Jan 2021 17:50:10 -0800 From: bob prohaska To: bob prohaska Cc: Current FreeBSD , freebsd-arm@freebsd.org Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld Message-ID: <20210118015009.GA31353@www.zefox.net> References: <20210116043740.GA19523@www.zefox.net> <20210116155538.GA24259@www.zefox.net> <20210116220334.GA26756@www.zefox.net> <20210117174006.GA30728@www.zefox.net> <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> X-Rspamd-Queue-Id: 4DJvqh0Lzhz4mQy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [-1.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-arm]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 01:50:09 -0000 On Sun, Jan 17, 2021 at 12:30:51PM -0800, Mark Millard wrote: > > > On 2021-Jan-17, at 09:40, bob prohaska wrote: > > > On Sat, Jan 16, 2021 at 03:04:04PM -0800, Mark Millard wrote: > >> > >> Other than -j1 style builds (or equivalent), one pretty much > >> always needs to go looking around for a non-panic failure. It > >> is uncommon for all the material to be together in the build > >> log in such contexts. > > > > Running make cleandir twice and restarting -j4 buildworld brought > > the process full circle: A silent hang, no debugger response, no > > console warnings. That's what sent me down the rabbit hole of make > > without clean, which worked at least once... > > Unfortunately, such a hang tends to mean that log files and such > were not completely written out to media. We do not get to see > evidence of the actual failure time frame, just somewhat before. > (compiler/linker output and such can have the same issues of > ending up with incomplete updates.) > > So, pretty much my notes are unlikely to be strongly tied to > any solid evidence: more like alternatives to possibly explore > that could be far off the mark. > > It is not clear if you were using: > > LDFLAGS.lld+= -Wl,--threads=1 > > or some such to limit the multi-thread linking and its memory. No, I wasn't trying to limit ld.lld thread number. > I'll note that if -j4 gets 4 links running in parallel it used > to be each could have something like 5 threads active on a 4 > core machine, so 20 or so threads. (I've not checked llvm11's > lld behavior. It might avoid such for defaults.) > > You have not reported any testing of -j2 or -j3 so far, just > -j4 . (Another way of limiting memory use, power use, temperature, > etc. .) > Not recently, simply because it's so slow to build. On my "production" armv7 machines running stable/12 I do use -j2. But, they get updated only a couple times per year, when there's a security issue. > You have not reported if your boot complained about the swap > space size or if you have adjusted related settings to make > non-default tradeoffs for swap amanagment for these specific > tests. I recommend not tailoring and using a swap size total > that is somewhat under what starts to complain when there is > no tailoring. > Both Pi2 and Pi3 have been complaining about too much swap since I first got them. Near as can be told it's never been a demonstrated problem, thus far. Now, as things like LLVM get bigger and bigger, it seems possible excess swap might cause, or obscure, other problems. For the Pi2 I picked 2 GB from the old "2x physical RAM" rule. > > > The residue of the top screen shows > > > > last pid: 63377; load averages: 4.29, 4.18, 4.15 up 1+07:11:07 04:46:46 > > 60 processes: 5 running, 55 sleeping > > CPU: 70.7% user, 0.0% nice, 26.5% system, 2.8% interrupt, 0.0% idle > > Mem: 631M Active, 4932K Inact, 92M Laundry, 166M Wired, 98M Buf, 18M Free > > Swap: 2048M Total, 119M Used, 1928M Free, 5% Inuse, 16K In, 3180K Out > > packet_write_wait: Connection to 50.1.20.26 port 22: Broken pipe > > bob@raspberrypi:~ $ ssh www.zefox.com RES STATE C TIME WCPU COMMAND > > ssh: connect to host www.zefox.com port 22: Connection timed out86.17% c++ > > bob@raspberrypi:~ $ 1 99 0 277M 231M RUN 0 3:26 75.00% c++ > > 63245 bob 1 99 0 219M 173M CPU0 0 2:10 73.12% c++ > > 62690 bob 1 98 0 354M 234M RUN 3 9:42 47.06% c++ > > 63377 bob 1 30 0 5856K 2808K nanslp 0 0:00 3.13% gstat > > 38283 bob 1 24 0 5208K 608K wait 2 2:00 0.61% sh > > 995 bob 1 20 0 6668K 1184K CPU3 3 8:46 0.47% top > > 990 bob 1 20 0 12M 1060K select 2 0:48 0.05% sshd > > .... > > This does not look like ld was in use as of the last top > display update's content. But the time between reasonable > display updates is fairly long relative to CPU activity > so it is only suggestive. > > > [apologies for typing over the remnants] > > > > I've put copies of the build and swap logs at > > > > http://www.zefox.net/~fbsd/rpi2/buildworld/ > > > > The last vmstat entry (10 second repeat time) reports: > > procs memory page disks faults cpu > > r b w avm fre flt re pi po fr sr da0 sd0 in sy cs us sy id > > 4 0 14 969160 91960 685 2 2 1 707 304 0 0 11418 692 1273 45 5 50 > > > > Does that point to the memory exhaustion suggested earlier in the thread? > > At this point /boot/loader.conf contains vm.pfault_oom_attempts="-1", but > > that's a relic of long-ago attempts to use USB flash for root and swap. > > Might removing it stimulate more warning messages? > > > > vm.pfault_oom_attempts="-1" should only be used in contexts where > running out of swap will not happen. Otherwise a deadlocked system > can result if it does run out of swap. (Run-out has more senses the > just the swap partition being fully used: other internal resources > for keeping track of the swap can run into its limits.) I've no > evidence that the -1 was actually a problem. > > I do not find any 1000+ ms/w or ms/r figures in swapscript.log . > I found 3 examples of a little under 405 (on sdda0*), 3 between > 340 and 345 (da0*), 4 in the 200s (da0*), under 60 in the 100s > (da0*). It does not look to me like the recorded part had problems > with the long latencies that you used to have happen. > > So I've not found any specific evidence about what led to the > hangup. So my earlier questions/suggestions are basically > arbitrary and I would not know what to do with any answers > to the questions. > > The only notes that are fairly solid are about the hangup leading > to there being some files that were likely incompletely updated > (logs, compiler output files, etc.). > The notion that log files might be truncated didn't didn't register until you brought it up. The obvious things to try seem to be: Disable vm.pfault_oom_attempts="-1" Decrease swap partition size Try using WITH_META_MODE WITH_META_MODE seems relatively easy; just add -DWITH_META_MODE to the make command line for buildworld and add filemon_load="YES" to boot/loader.conf, but I wonder about the burdens it'll impose on CPU and disk space/throughput. There's nothing to lose at this stage, but I'm all ears if there's a better approach. Many thanks for your patient good counsel! bob prohaska From owner-freebsd-arm@freebsd.org Mon Jan 18 03:19:40 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 130E04E061D for ; Mon, 18 Jan 2021 03:19:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJxpy6VrLz4rLd for ; Mon, 18 Jan 2021 03:19:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610939976; bh=mMtz4Pmk/Q13cf2An/iYxt93mJQsuApiWkqsj1E+/oQ=; h=Subject:From:Date:To:From:Subject:Reply-To; b=MULPrbu3QAFfg7UKvW626PrjoraGm+VfW77T2LWjPbulgaq78xlEQLy+kyvp01vXMIRuVkJZ2LP1kEmF3BWMnKR50Hq79g0iuATZfaom6SZBCEU48uAYsTa2LLpPn8C53TstsC8eQKi7mPAPqh0itQsETOTvc2S6QS9987Ehvquf6Ud+B+BKvwh4Mz/X6sMK4Vkx0X5im/G9iYHRo9djfNDogpqcvO9wLsWSTQxXxjzXYi2GNoVwDP7G5iaKAVKRQJlwzOsuCg59/j8eHJNTnN8+fXYMSerth/ERfhOB7TWsa6DvbsCdOTKhJfFjcnro2yYFPTu+wU1LICnD0MsRow== X-YMail-OSG: lERwqYgVM1n7RAbmxdOGMztN2sTDsgg6Iy7CrRLtRBnJzKGZ9zYcUuIMx5csGwJ QscIuBHaUvd68oUHGleaz0p4yf122CIbz9ACoGrwAY8kqz6V5wrtRtXA0CaHA_r.TXxtZcmMGpIS Ih.28jKhYy6kAUMmnUm2ye4dxuzqpwhQaH3bUGe3TDYhBOVxml84AdlWOuO5rhvWn9xiztVuxmD0 CRYUQv5VCSP3hvmmiW.K.A68xGbiwMwpnXnxBa36BLZInBzsvesY.p8djmaezzfrO8YLGSSmqiaG 70bi5cUzhB_PALBwGKIGIKGsJy8JtYyus7ldkFrNz.WidJxrhuzyNPejssxu_3P_7vWu5z9zDCqD JLSOaLtuLP9aaQRQMkhzFj256hF_JaMvbV0VRGeiT279AmqWLJFhHCMclbItuxFXlnd8RjRtPXRd NCZ.5uvfdfrN4lYT4kZEMiPTlxD8JIX73q1IAj7PSvw_LEcRKfz_X.HU7qLyCafjSTcn4aboeOdv bSC73K4o1slcpty_ZIGRjrZGBUofPp9QLwy7JY_cYdXLXXn7i.NngwaWmPUu3qQopb0oMPqu26BR 6OyUxEoVqYPA0LDHpF4KylhiqLY999DMMyykxJzx221OmFukWdjBg8HQc9yTrATzj6.SiqBZ0T4D Te9O5wgeod4zgwkNMiRjNy4FB.bAHAAlBOtNefVb78CbMVEtb3GNUMlYihOmKJ0JVR.uUy0N99_D 33XfbLWiUJuCom.NM3RmnFwccg6HNgC.gYObe.gMt_Dil..Ll6uQxud8JJGQY8c9y0W7L12WO37s dY9lQdSnL9p8WkeJSmTcULUEgv3z0U8.ZNd8B8noYyLafmeUmHJMVd0_LvVThcygwgq_iJM0PFiw L.4xjm5CZMQ8PlZtn4pXGYyEN9BS2O5IW8V0ZIpyQXTqxM2tgxIbgm_yCQoVNO1wEB8z4p_4KXHs zCwVwKGiMi_1.9HOp34DbJVe1zyr3LXfyi8A1bQnt5b6.r2ks91zvZC6ozJ2HaskvZu98TTQ47Ok 2oOejzhmRCXo9BW2ZN_TFQqrEKZbWtDzb5ufEYjr4iohgr5fPfcOc5_tOwTLvjfnR5o529x1EGO_ kaA6KD4NKkviUXlmJWkf3VJ7QoAysBjshd2bhmXLGinbsXbq49SYsPuyEH8pb0h3DS65m1voe7Af Odrcj3s3wUip6fTbplOlCcIO3y7AOf2nGgDz00OZLCC09Se6Pl6SzM8o_ylzgbP19lBNzdZ8aeua sGq2mdy8wJYY6bMT3rWK9ir1rUAj6CLtqbUNr7zBIT614BAAKhcbs.NihcXpw9jxkuLewv7K2zHz o0.Y27kUAk8CnWMRX105AIlM9fk9BHOFoVc1DR1gOfv5.J2habCbTBxLhRTC42M1XKAYvH4iKQHD j945vEjQzgPH.DjMjqsxTOMj_LQrQFqyaNsdPA7eCIjyeko44QDl7AgOICj7upG87xb5pNNCxifp 4k9u5n8gFeogNdK7tY36dPokKXskpEc2YgE.8ZBNYbDdRn_PLGC4AzAPVRHs_nJGFDGXVkjtsayL pkqiqyI.8BXeQTqmvCA31ivhIKd0zkVOxC17RKmBQHPUIuo_ehTSYB_FQnb4aI8CRR77Iw2fRfsT ax_JvDcgjiYE_VcieYTBIgwZ7WWF5I.LrQHVSkTWFKhWU5SCAid_UY8J18TsTsPiAx7rQY6G_9ir iz8nHx9asiIFnFjCPRq7dMHLeet1UJFNYVEVkDRa5cqOThm8zexxt8Io9wajUCloNChUqeoE.5Rq Ym0gzqOxyDMYHWdaikWm7PZT4qakGoBtOCm1gqdqfvaGpsD.J3LNyZ3xZW23qPpAxIxxvbIq0gRd IbTD.Dms3MgFtg7yzY0Yyflci_EDprzCVzrArciD9VvclRw8p3b1IvU24M8W6iuyZI6WGWg0IF.o U5uitQJsaQudloz2TdJ9.KANEuFj6arT_iRxV84tn6fgYINXgZUi9ms29xE6Y3asq3gFMA1MhCDh yEPQtJ93rhvcqZHu3nQ.koGZLnFQbTFG6y_hhVj0XcTHprqZdjhNp_1E6O5IBNviCtrGpdJWMqoH Zg4O32qPLDlhmkZzjesuP36ulHrPVuKqBnQ28sulJF0IzbqjpqTRZa7lAEFGSht.WMHnLzmshooZ xm3vPqLVgXeAKXoK6JvaqHILrLjB6yuhyfyr8w4b8MqbmbYAKChSHqKg.zRVlBRnZO8YY_nVznP8 Q7PrXV7QtVc8P8mc85tSK3o82wQwtW4NEEnO12LyK2Ic_fcNZQtWl4RO6VvCgi1knmoQ90OsZqOD HXYOePVRIv3bZCM6Q7zvdn2iWntqLvOF.Sf.RIx0Hn_0coZFMxoJdlEGXhGVdHR2Auckkuvpgz9a N_oJwGDZFPW3X_OwNZ4O15bzlrX1EJF7fZhZ6PrZPQOZoQTkPs7mPNxoKXDDQfv9KNQc5tFXl0Wf F8_AiDnOElik_lTHKVL2a8Ayg9MCxIPUXjUdnnnWQn4ca8uD.10MpGpR20V0rIYPxS15eSDRC0UO 2m5EhhzT8D3aPOLyjuNQ4F6M8nsu.Vm5ocf0NYjB8Idn1YURzEgUfoz4b.iXGtXyw3eZVbo.j0ov J_jU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 18 Jan 2021 03:19:36 +0000 Received: by smtp403.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b43a1661d3f58183e7d34af0db0876b0; Mon, 18 Jan 2021 03:19:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <20210118015009.GA31353@www.zefox.net> Date: Sun, 17 Jan 2021 19:19:33 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> References: <20210116043740.GA19523@www.zefox.net> <20210116155538.GA24259@www.zefox.net> <20210116220334.GA26756@www.zefox.net> <20210117174006.GA30728@www.zefox.net> <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DJxpy6VrLz4rLd X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 03:19:40 -0000 On 2021-Jan-17, at 17:50, bob prohaska wrote: > On Sun, Jan 17, 2021 at 12:30:51PM -0800, Mark Millard wrote: >>=20 >>=20 >> On 2021-Jan-17, at 09:40, bob prohaska wrote: >>=20 >>> On Sat, Jan 16, 2021 at 03:04:04PM -0800, Mark Millard wrote: >>>>=20 >>>> Other than -j1 style builds (or equivalent), one pretty much >>>> always needs to go looking around for a non-panic failure. It >>>> is uncommon for all the material to be together in the build >>>> log in such contexts. >>>=20 >>> Running make cleandir twice and restarting -j4 buildworld brought >>> the process full circle: A silent hang, no debugger response, no >>> console warnings. That's what sent me down the rabbit hole of make >>> without clean, which worked at least once... >>=20 >> Unfortunately, such a hang tends to mean that log files and such >> were not completely written out to media. We do not get to see >> evidence of the actual failure time frame, just somewhat before. >> (compiler/linker output and such can have the same issues of >> ending up with incomplete updates.) >>=20 >> So, pretty much my notes are unlikely to be strongly tied to >> any solid evidence: more like alternatives to possibly explore >> that could be far off the mark. >>=20 >> It is not clear if you were using: >>=20 >> LDFLAGS.lld+=3D -Wl,--threads=3D1 >>=20 >> or some such to limit the multi-thread linking and its memory. > No, I wasn't trying to limit ld.lld thread number. You might want to try a significant change in the memory use just to see if it makes a difference or not --despite the extra time. This could included limiting lld thread usage and limiting to a smaller -jN . >> I'll note that if -j4 gets 4 links running in parallel it used >> to be each could have something like 5 threads active on a 4 >> core machine, so 20 or so threads. (I've not checked llvm11's >> lld behavior. It might avoid such for defaults.) >>=20 >> You have not reported any testing of -j2 or -j3 so far, just >> -j4 . (Another way of limiting memory use, power use, temperature, >> etc. .) >>=20 > Not recently, simply because it's so slow to build. On my "production" > armv7 machines running stable/12 I do use -j2. But, they get updated > only a couple times per year, when there's a security issue.=20 See the earlier note about possibly deliberate test of using less memory space. (And more later, below.) >> You have not reported if your boot complained about the swap >> space size or if you have adjusted related settings to make >> non-default tradeoffs for swap amanagment for these specific >> tests. I recommend not tailoring and using a swap size total >> that is somewhat under what starts to complain when there is >> no tailoring. >>=20 > Both Pi2 and Pi3 have been complaining about too much swap > since I first got them. Near as can be told it's never been > a demonstrated problem, thus far. Now, as things like LLVM > get bigger and bigger, it seems possible excess swap might > cause, or obscure, other problems. For the Pi2 I picked 2 > GB from the old "2x physical RAM" rule.=20 I'd take those warnings as FreeSD reporting that the system is expected to be in a mistuned configuration by "normal" criteria. Doing the tuning to allow more swap has the documented tradeoffs: kern.maxswzone . . . Note that swap metadata can be fragmented, which means = that the system can run out of space before it reaches the theoretical limit. Therefore, care should be taken to = not configure more swap than approximately half of the theoretical maximum. (The above is what the warning is about. But then there is . . .) Running out of space for swap metadata can leave the = system in an unrecoverable state. Therefore, you should only change this parameter if you need to greatly extend the = KVM reservation for other resources such as the buffer cache = or kern.ipc.nmbclusters. Modifies kernel option VM_SWZONE_SIZE_MAX. (NOTE: That last paragraph is talking about *decreasing* kern.maxswzone to get more room for non-swap-managment things in KVM. [Too bad the wording says "change".] But increasing kern.maxswzone to allow more swap leaves less space for the buffer cache or like, making for tradeoffs being involved.) >>> The residue of the top screen shows >>>=20 >>> last pid: 63377; load averages: 4.29, 4.18, 4.15 = up 1+07:11:07 04:46:46 >>> 60 processes: 5 running, 55 sleeping >>> CPU: 70.7% user, 0.0% nice, 26.5% system, 2.8% interrupt, 0.0% = idle >>> Mem: 631M Active, 4932K Inact, 92M Laundry, 166M Wired, 98M Buf, 18M = Free >>> Swap: 2048M Total, 119M Used, 1928M Free, 5% Inuse, 16K In, 3180K = Out >>> packet_write_wait: Connection to 50.1.20.26 port 22: Broken pipe >>> bob@raspberrypi:~ $ ssh www.zefox.com RES STATE C TIME = WCPU COMMAND >>> ssh: connect to host www.zefox.com port 22: Connection timed = out86.17% c++ >>> bob@raspberrypi:~ $ 1 99 0 277M 231M RUN 0 3:26 = 75.00% c++ >>> 63245 bob 1 99 0 219M 173M CPU0 0 2:10 = 73.12% c++ >>> 62690 bob 1 98 0 354M 234M RUN 3 9:42 = 47.06% c++ >>> 63377 bob 1 30 0 5856K 2808K nanslp 0 0:00 = 3.13% gstat >>> 38283 bob 1 24 0 5208K 608K wait 2 2:00 = 0.61% sh >>> 995 bob 1 20 0 6668K 1184K CPU3 3 8:46 0.47% = top >>> 990 bob 1 20 0 12M 1060K select 2 0:48 0.05% = sshd >>> .... >>=20 >> This does not look like ld was in use as of the last top >> display update's content. But the time between reasonable >> display updates is fairly long relative to CPU activity >> so it is only suggestive. >>=20 >>> [apologies for typing over the remnants] >>>=20 >>> I've put copies of the build and swap logs at >>>=20 >>> http://www.zefox.net/~fbsd/rpi2/buildworld/ >>>=20 >>> The last vmstat entry (10 second repeat time) reports: >>> procs memory page disks faults = cpu >>> r b w avm fre flt re pi po fr sr da0 sd0 in sy = cs us sy id >>> 4 0 14 969160 91960 685 2 2 1 707 304 0 0 11418 = 692 1273 45 5 50 >>>=20 >>> Does that point to the memory exhaustion suggested earlier in the = thread? >>> At this point /boot/loader.conf contains = vm.pfault_oom_attempts=3D"-1", but=20 >>> that's a relic of long-ago attempts to use USB flash for root and = swap. >>> Might removing it stimulate more warning messages? >>>=20 >>=20 >> vm.pfault_oom_attempts=3D"-1" should only be used in contexts where >> running out of swap will not happen. Otherwise a deadlocked system >> can result if it does run out of swap. (Run-out has more senses the >> just the swap partition being fully used: other internal resources >> for keeping track of the swap can run into its limits.) I've no >> evidence that the -1 was actually a problem. >>=20 >> I do not find any 1000+ ms/w or ms/r figures in swapscript.log . >> I found 3 examples of a little under 405 (on sdda0*), 3 between >> 340 and 345 (da0*), 4 in the 200s (da0*), under 60 in the 100s >> (da0*). It does not look to me like the recorded part had problems >> with the long latencies that you used to have happen. >>=20 >> So I've not found any specific evidence about what led to the >> hangup. So my earlier questions/suggestions are basically >> arbitrary and I would not know what to do with any answers >> to the questions. >>=20 >> The only notes that are fairly solid are about the hangup leading >> to there being some files that were likely incompletely updated >> (logs, compiler output files, etc.). >>=20 >=20 > The notion that log files might be truncated didn't didn't register=20 > until you brought it up.=20 >=20 > The obvious things to try seem to be: > Disable vm.pfault_oom_attempts=3D"-1" > Decrease swap partition size > Try using WITH_META_MODE I'll note that you may well have already spent more time not getting complete builds than doing one "use less memory" test would have taken (linker thread count limits, smaller -jN). To find fairly optimal settings for building on the RPi2 V1.1, you may have to explore on both sides of the optimal settings range, just to identify the optimal range for the settings as being between known bounds. Of course, for all I know, the "use less memory" tests might also fail. If that happened, it would tend to stop spending time testing configurations even less likely to finish building. > WITH_META_MODE seems relatively easy; just add -DWITH_META_MODE to = the make > command line for buildworld and add filemon_load=3D"YES" to = boot/loader.conf, > but I wonder about the burdens it'll impose on CPU and disk = space/throughput.=20 > There's nothing to lose at this stage, but I'm all ears if there's a = better > approach. You could trade off some I/O by not generating swapscript.log since it seems to not be of much help for the current issue. I'll also note that META_MODE by default does not generate as much stdout text but stores more across the various .meta files. So, by default, buildworld.log (by itself) would be much smaller. (So disabling recording of buildworld.log would not make much of a difference.) I'll remind of the things that are environment-only variables, including WITH_META_MODE : QUOTE The environment of make(1) for the build can be controlled via the SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some examples that may only be set in this file are WITH_DIRDEPS_BUILD, = and WITH_META_MODE, and MAKEOBJDIRPREFIX as they are environment-only variables. END QUOTE "may only be set in this file" is false relative to setting the enviromnent on the command line but true compared to the likes of putting the text in /etc/src.conf or the like. My script for building for armv7 in a armv7 context looks something like: script = ~/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-armv7-host= -$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.armv7-clang-bootstrap.armv7-hos= t" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/armv7_clang/arm.armv7" \ make $* (So I happened to not use -DWITH_META_MODE . The context is /bin/sh based, by the way.) There are contexts for which I control UBLR_LOADADDR via an additional line in the above, such as: WORLD_FLAGS=3D"${WORLD_FLAGS} UBLDR_LOADADDR=3D0x42000000" \ (But such is old material that I've not validated as being needed in even remotely modern times.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Jan 18 08:45:16 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 01F7E4E5922 for ; Mon, 18 Jan 2021 08:45:16 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DK52d6sf0z3PZp for ; Mon, 18 Jan 2021 08:45:13 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1610959511; 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=1ECUQu/Ue2LONCJddMjbtZBcQtWTYnVZ9agzoZ9JLFE=; b=GL8pYEhdhhwRfP7EsFhMtflTrmcWbg3dcefefBLbtcNjNlcnaeVU1cSgOL3OrGzvRJbDUu 8x9ZP/51bVMhvDIsrSnp+BTuM42kI8vACV4D0GubeWJWZ3RGTzUm5/gdJxl2TI7LCMFG25 hPxUfrDmNWg3afdTExlcmJw+i6tYLmg= Received: from skull.home.blih.net (lfbn-idf2-1-745-114.w86-247.abo.wanadoo.fr [86.247.192.114]) by mx.blih.net (OpenSMTPD) with ESMTPSA id dd20ef76 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 18 Jan 2021 08:45:10 +0000 (UTC) Date: Mon, 18 Jan 2021 09:45:10 +0100 From: Emmanuel Vadot To: "Dr. Rolf Jansen" Cc: freebsd-arm@freebsd.org Subject: Re: GENERICSD snapshot on a BBB has issues with loading the if_rtwn_usb module Message-Id: <20210118094510.48eee03d502ea25ab7d09938@bidouilliste.com> In-Reply-To: <03F9A3D3-0A2B-4B09-9C8D-AAAF761C0F4C@obsigna.com> References: <47700631-2D94-4BA8-9707-9ADD70C99600@obsigna.com> <20210116184333.f91594f9c3505d2c588d9634@bidouilliste.com> <20210116184833.1a3182a20a2b6c727b64bb59@bidouilliste.com> <06F689CA-B781-4CEB-8F8A-B00FAC684DD3@obsigna.com> <20210117174539.43b55379e6a37881589616a8@bidouilliste.com> <20210117225539.c113796159735c5a3950c774@bidouilliste.com> <03F9A3D3-0A2B-4B09-9C8D-AAAF761C0F4C@obsigna.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DK52d6sf0z3PZp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=GL8pYEhd; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[212.83.155.74:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.83.155.74:from]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 08:45:16 -0000 On Sun, 17 Jan 2021 19:01:24 -0300 "Dr. Rolf Jansen" wrote: > > Am 17.01.2021 um 18:55 schrieb Emmanuel Vadot : > > > > On Sun, 17 Jan 2021 18:49:01 -0300 > > "Dr. Rolf Jansen" wrote: > > > >>> Am 17.01.2021 um 13:45 schrieb Emmanuel Vadot : > >>> > >>> On Sat, 16 Jan 2021 15:11:28 -0300 > >>> "Dr. Rolf Jansen" > wrote: > >>> > >>>>> Am 16.01.2021 um 14:48 schrieb Emmanuel Vadot >: > >>>>> > >>>>> On Sat, 16 Jan 2021 18:43:33 +0100 > >>>>> Emmanuel Vadot >> wrote: > >>>>> > >>>>>> On Sat, 16 Jan 2021 14:08:58 -0300 > >>>>>> "Dr. Rolf Jansen" wrote: > >>>>>> > >>>>>>> I updated one of my BBB from an older 13-CURRENT (July 2020) to the latest 13-ALPHA1 snapshot from Jan, 14th ? GENERICSD-20210114-7ae27c2d6c4-255938. > >>>>>>> > >>>>>>> I had successfully employed an USB-WLAN dongle based on the RTL8188eu chipset. I only added the following into /boot/loader.conf: > >>>>>>> > >>>>>>> if_rtwn_usb_load="YES" > >>>>>>> > >>>>>>> By that all dependend modules were loaded automatically in a snap. With ALPHA1 this doesn?t work anymore. After hours of troubleshooting, I got it working by adding the following into /etc/rc.conf: > >>>>>>> > >>>>>>> kld_list="if_rtwn_usb" > >>>>>>> > >>>>>>> The "Loading kernel modules:" takes apprx. 4 seconds, however, then the USB-WLAN device is enumerated correctly and it is ready to use. This makes me think that this uncommon huge delay is the culprit. I checked this with some snapshot thats I had installed already. The issue seems to have been introduced together with the switch to GENERICSD. A GENERICSD 13-CURRENT from end of December showed this issue already, while a BBB-specific snapshot (from November 2020) that I had installed on another BBB works as before by loading the modules in /boot/loader.conf. > >>>>>>> > >>>>>>> I don't mind to load the modules by the way of the kld_list directive in /etc/rc.conf. However, the unusual long duration of loading the module and its dependencies might be an indication for a more fundamental issue. > >>>>>>> > >>>>>>> Please feel free to ask me for doing more tests. > >>>>>>> > >>>>>>> Best regards > >>>>>>> > >>>>>>> Rolf > >>>>>> > >>>>>> I can reproduce that on my netbooted BBB. > >>>>>> The module is correctly loaded : > >>>>>> > >>>>>> Loading > >>>>>> kernel... /boot/kernel/kernel text=0x1b4 text=0x68d638 text=0x1c84f0 > >>>>>> data=0xb4070 data=0x0+0x258000 syms=[0x4+0xa5ab0+0x4+0x119fd4] Loading > >>>>>> configured modules... /boot/kernel/if_rtwn_usb.ko text=0xb960 > >>>>>> text=0x62c0 data=0x2cc+0x3b syms=[0x4+0x3570+0x4+0x293f] /boot/entropy > >>>>>> size=0x1000 /etc/hostid > >>>>>> size=0x25 Using DTB provided by EFI at > >>>>>> 0x87f00000. Kernel entry at > >>>>>> 0x96e00200... Kernel args: > >>>>>> (null) > >>>>>> ---<>--- > >>>>>> > >>>>>> But it isn't loaded anymore after booting : > >>>>>> root@bbb:~ # kldstat > >>>>>> Id Refs Address Size Name > >>>>>> 1 1 0xc0000000 d23a8c kernel > >>>>>> > >>>>>> I don't think it has to do with the switch to GENERICSD, there is (at > >>>>>> least shouldn't be) any difference between the old BBB image and the > >>>>>> GENERICSD one. > >>>> > >>>> Yes, this might well be a coincidence. I do neither have the last BBB specific snapshot nor the first GENERICSD one for testing these against each other. > >>>> > >>>>> Just did a test on my OrangePi One (Allwinner H3 armv7 with 512MB of > >>>>> RAM) and this is the same. > >>>>> The problem seems to be module dependancy, loader only loads > >>>>> if_rtnw_usb but doing a kldload also brings wlan.ko and rtwn.ko > >>>> > >>>> I can confirm this. And in addition loading the if_rtwn_usb.ko module and its dependcies manually also takes now significantly longer compared to a manual load on the BBB specific 13-CURRENT from November. Perhaps something has been changed in the dependency resolver. > >>>> > >>> > >>> Fixed in 0f2434ea000e > >>> > >>> Thanks for reporting. > >> > >> Unfortunately, this did not resolve the issue. I updated my working copy with git pull and verified that your changes made it into my source tree. Then I built a new kernel and replaced the original ALPHA1 kernel from 2021-01-14 by this new one. The rtwn-modules are still not loaded by the if_rtwn_usb_load="YES" directive in /boot/loader.conf. > >> > >> Best regards > >> > >> Rolf > > > > You need to update loader.efi on the ESP partition. > > Please excuse my ignorance. Do I need to build world for this? Then where is the newly build loader.efi? > > Best regards > > Rolf It's part of buildworld yes but you can rebuild it with : (cd stand/ && make buildenv TARGET_ARCH=armv7 BUILDENV_SHELL="make clean all -sj4") Then locate loader_lua.efi in the obj directory and place it in the ESP (the fat16/fat32 partition) as efi/boot/bootarm.efi -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Jan 18 12:03:00 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 80DA24E9B7C for ; Mon, 18 Jan 2021 12:03:00 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DK9Qp6gKTz3rBG for ; Mon, 18 Jan 2021 12:02:58 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1610971376; s=strato-dkim-0002; d=obsigna.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:From: Subject:Sender; bh=9isi+x/R8/3uDJzkKhPJ3GPm1Nkm8lk8/Rn0ZhMAkSg=; b=L6n4fvldnx4LAmhCpZu+qQiUFMm5ofKB1CDTqHX0AN4Wvt4lvD9YNDEOdZpQyRc+Xv o7SvpfHx7JPd29UjwC1cVPUvW7Ljn9+EerDsuokJPePxd/PmgJaJN5dZfX9qnCm6ddTF LS+mwRTwDoTAepoOBZt775DMYzbthrjUDeGKTaj57XQ9yIU3SWvlx4/BRlU6t9F4+Qt6 7u2cMT4p4UHgSzqxRIyth0+UiFoWmsKaucv28qdtCE5Jn0ZK5f6YPJj59o+7ADhG3Zcg QuA6a+/YFNq3/OsauqwaC5DW1pt/M5WPXdwA4FBpf/bBTQHRpyxw9QsV8g3qOn1Ahj4Z 5q7g== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio0dVVInWnas+zpAhAiA/W" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 47.12.1 DYNA|AUTH) with ESMTPSA id d0872bx0IC2tlQT (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 18 Jan 2021 13:02:55 +0100 (CET) Received: from rolf-aux.obsigna.com (rolf-aux.obsigna.com [192.168.222.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 036CE1350F946; Mon, 18 Jan 2021 09:02:50 -0300 (-03) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: GENERICSD snapshot on a BBB has issues with loading the if_rtwn_usb module From: "Dr. Rolf Jansen" In-Reply-To: <20210118094510.48eee03d502ea25ab7d09938@bidouilliste.com> Date: Mon, 18 Jan 2021 09:02:50 -0300 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9F0684B2-02EA-4647-BA02-8C6F80C421F7@obsigna.com> References: <47700631-2D94-4BA8-9707-9ADD70C99600@obsigna.com> <20210116184333.f91594f9c3505d2c588d9634@bidouilliste.com> <20210116184833.1a3182a20a2b6c727b64bb59@bidouilliste.com> <06F689CA-B781-4CEB-8F8A-B00FAC684DD3@obsigna.com> <20210117174539.43b55379e6a37881589616a8@bidouilliste.com> <20210117225539.c113796159735c5a3950c774@bidouilliste.com> <03F9A3D3-0A2B-4B09-9C8D-AAAF761C0F4C@obsigna.com> <20210118094510.48eee03d502ea25ab7d09938@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4DK9Qp6gKTz3rBG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=obsigna.com header.s=strato-dkim-0002 header.b=L6n4fvld; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@obsigna.com designates 85.215.255.25 as permitted sender) smtp.mailfrom=freebsd-rj@obsigna.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24]; RWL_MAILSPIKE_GOOD(0.00)[85.215.255.25:from]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[obsigna.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[85.215.255.25:from]; ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[obsigna.com:s=strato-dkim-0002]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[obsigna.com]; SPAMHAUS_ZRD(0.00)[85.215.255.25:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[85.215.255.25:from]; FROM_NAME_HAS_TITLE(1.00)[dr]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 12:03:00 -0000 > Am 18.01.2021 um 05:45 schrieb Emmanuel Vadot : >=20 > On Sun, 17 Jan 2021 19:01:24 -0300 > "Dr. Rolf Jansen" wrote: >=20 >>> Am 17.01.2021 um 18:55 schrieb Emmanuel Vadot = : >>>=20 >>> On Sun, 17 Jan 2021 18:49:01 -0300 >>> "Dr. Rolf Jansen" wrote: >>>=20 >>>>> Am 17.01.2021 um 13:45 schrieb Emmanuel Vadot = : >>>>>=20 >>>>> On Sat, 16 Jan 2021 15:11:28 -0300 >>>>> "Dr. Rolf Jansen" > wrote: >>>>>=20 >>>>>>> Am 16.01.2021 um 14:48 schrieb Emmanuel Vadot = >: >>>>>>>=20 >>>>>>> On Sat, 16 Jan 2021 18:43:33 +0100 >>>>>>> Emmanuel Vadot >> wrote: >>>>>>>=20 >>>>>>>> On Sat, 16 Jan 2021 14:08:58 -0300 >>>>>>>> "Dr. Rolf Jansen" wrote: >>>>>>>>=20 >>>>>>>>> I updated one of my BBB from an older 13-CURRENT (July 2020) = to the latest 13-ALPHA1 snapshot from Jan, 14th ? = GENERICSD-20210114-7ae27c2d6c4-255938. >>>>>>>>>=20 >>>>>>>>> I had successfully employed an USB-WLAN dongle based on the = RTL8188eu chipset. I only added the following into /boot/loader.conf: >>>>>>>>>=20 >>>>>>>>> if_rtwn_usb_load=3D"YES" >>>>>>>>>=20 >>>>>>>>> By that all dependend modules were loaded automatically in a = snap. With ALPHA1 this doesn?t work anymore. After hours of = troubleshooting, I got it working by adding the following into = /etc/rc.conf: >>>>>>>>>=20 >>>>>>>>> kld_list=3D"if_rtwn_usb" >>>>>>>>>=20 >>>>>>>>> The "Loading kernel modules:" takes apprx. 4 seconds, however, = then the USB-WLAN device is enumerated correctly and it is ready to use. = This makes me think that this uncommon huge delay is the culprit. I = checked this with some snapshot thats I had installed already. The issue = seems to have been introduced together with the switch to GENERICSD. A = GENERICSD 13-CURRENT from end of December showed this issue already, = while a BBB-specific snapshot (from November 2020) that I had installed = on another BBB works as before by loading the modules in = /boot/loader.conf. >>>>>>>>>=20 >>>>>>>>> I don't mind to load the modules by the way of the kld_list = directive in /etc/rc.conf. However, the unusual long duration of loading = the module and its dependencies might be an indication for a more = fundamental issue. >>>>>>>>>=20 >>>>>>>>> Please feel free to ask me for doing more tests.=20 >>>>>>>>>=20 >>>>>>>>> Best regards >>>>>>>>>=20 >>>>>>>>> Rolf >>>>>>>>=20 >>>>>>>> I can reproduce that on my netbooted BBB. >>>>>>>> The module is correctly loaded : >>>>>>>>=20 >>>>>>>> Loading >>>>>>>> kernel... /boot/kernel/kernel text=3D0x1b4 text=3D0x68d638 = text=3D0x1c84f0 >>>>>>>> data=3D0xb4070 data=3D0x0+0x258000 = syms=3D[0x4+0xa5ab0+0x4+0x119fd4] Loading >>>>>>>> configured modules... /boot/kernel/if_rtwn_usb.ko text=3D0xb960 >>>>>>>> text=3D0x62c0 data=3D0x2cc+0x3b syms=3D[0x4+0x3570+0x4+0x293f] = /boot/entropy >>>>>>>> size=3D0x1000 /etc/hostid >>>>>>>> size=3D0x25 Using DTB provided by EFI at >>>>>>>> 0x87f00000. Kernel entry at >>>>>>>> 0x96e00200... Kernel args: >>>>>>>> (null) = =20 >>>>>>>> ---<>--- = =20 >>>>>>>>=20 >>>>>>>> But it isn't loaded anymore after booting : >>>>>>>> root@bbb:~ # kldstat=20 >>>>>>>> Id Refs Address Size Name >>>>>>>> 1 1 0xc0000000 d23a8c kernel >>>>>>>>=20 >>>>>>>> I don't think it has to do with the switch to GENERICSD, there = is (at >>>>>>>> least shouldn't be) any difference between the old BBB image = and the >>>>>>>> GENERICSD one. >>>>>>=20 >>>>>> Yes, this might well be a coincidence. I do neither have the last = BBB specific snapshot nor the first GENERICSD one for testing these = against each other. >>>>>>=20 >>>>>>> Just did a test on my OrangePi One (Allwinner H3 armv7 with = 512MB of >>>>>>> RAM) and this is the same. >>>>>>> The problem seems to be module dependancy, loader only loads >>>>>>> if_rtnw_usb but doing a kldload also brings wlan.ko and rtwn.ko >>>>>>=20 >>>>>> I can confirm this. And in addition loading the if_rtwn_usb.ko = module and its dependcies manually also takes now significantly longer = compared to a manual load on the BBB specific 13-CURRENT from November. = Perhaps something has been changed in the dependency resolver. >>>>>>=20 >>>>>=20 >>>>> Fixed in 0f2434ea000e >>>>>=20 >>>>> Thanks for reporting. >>>>=20 >>>> Unfortunately, this did not resolve the issue. I updated my working = copy with git pull and verified that your changes made it into my source = tree. Then I built a new kernel and replaced the original ALPHA1 kernel = from 2021-01-14 by this new one. The rtwn-modules are still not loaded = by the if_rtwn_usb_load=3D"YES" directive in /boot/loader.conf. >>>>=20 >>>> Best regards >>>>=20 >>>> Rolf >>>=20 >>> You need to update loader.efi on the ESP partition. >>=20 >> Please excuse my ignorance. Do I need to build world for this? Then = where is the newly build loader.efi? >>=20 >> Best regards >>=20 >> Rolf >=20 > It's part of buildworld yes but you can rebuild it with : > (cd stand/ && make buildenv TARGET_ARCH=3Darmv7 BUILDENV_SHELL=3D"make > clean all -sj4") >=20 > Then locate loader_lua.efi in the obj directory and place it in the > ESP (the fat16/fat32 partition) as efi/boot/bootarm.efi This resolved the issue. Thank you very much and best regards Rolf= From owner-freebsd-arm@freebsd.org Mon Jan 18 17:51:47 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 013B54F1961 for ; Mon, 18 Jan 2021 17:51:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DKK9F3Q3Vz4lKP for ; Mon, 18 Jan 2021 17:51:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610992303; bh=lEsg7elEJjOot9rQJVWtswqAdIIFpiPo+Sy4U6L8lLe=; h=Subject:From:Date:To:From:Subject:Reply-To; b=rMqpstJcLvy8BhnafafFoqPwv7uPZF4P33SvW95QDDZPZV6hJlbdJiw4NfZ3j8eiYbCUBBCipL6KyK0rYHEyPFuEPqjLZv3L9F6NibX6BkLkd/2q6CxduYPxK7mijFP45bDxtfWXpemjd1u+jfBHDZzFkr/Q6LTu3YzuUHC3PjG+pSLfrlKh3YHxajscuGPGNm2/y7QdRcNFmPIyj8as2fqmPeF3A/lkikA9jocBXrO5bqRG9BxiOyIG8le35qilRznEaOTK1OF67ql3ATrCnAqtx0UQ329eQhgh2tjba/uVOj02zm108K/idpRo+odT4yyPUyYqu2X+Vc3fF1VifA== X-YMail-OSG: zYlgZD8VM1kZwzhiI.afT6.0PTu.97QtdJqE1JxAL82DzaIM8VDB3eH_4X2Lm51 .QuIJkcWmRCfI8pmAZb18f5VKRbwx.U9ZKbPtHqe3Gi4GzTN3bOJYUqkEdBmAB2hJXwfFGqOqSY0 Bm08sspkkhl1QM0rq4EFX06wn7vpeUp_iHDanAtoLyle3Blj7Ml4wqFzaaZAYm0_ms4lIbyrI7if CauK7gtaxU2o06YpYKMeO7pIJUYL56vnAKMUrsvQ7TXtHXyZNcN668AhJdNZc.mjI6XtM3pwehzH wQ0xa35MibKz9TX8EHmgmvW2MgVh9allbDwcD3qbvTd6Dl5S8aBSPcTDcVyNfMkPJCL0nzK0r85u TyAPYJx.Q0VzMGimFVO4xBDETewConbWeNftR14m_XUtF29JRwbYzFe5.KQssDb_2yibd5Fr47om O6rXf.ZbpQ3h35CnhUD8qNApSSUldBiGUnkvmc.2aY.wvcfNpkYwJxnTOJzimF.h0oUANcFkkUFD bQZ0cMAdNiLhivOSfXuPqAmthgKf8ux7.l4LHwW2pJLYrKs4SNs1UekDLwZlKlAfHMbt_2tvHhpi HnEZeR10IPOPxT.PxSR0UyFl3b8cGLPKMBeRfY1HDH8eSlMpMHL_yzfHeyniuDKFSbruZtshmCDP n3jJWAhACpVHSxccsbM3yrJfH6bKksgqrEzGiR4bIjUGkr4zDiAj9MxXmnopw8oI1AouSv.E9NeX Rk27bI9aGsvmGBVT_MlELRPEkP93nIuadKKHCjBBAn7aXulBnDhS_D65hc5ukLYzClPqNBaHbyd0 BJr5NVvTPMgzYw3qpU3X9jlXXToirwTxnPkCqR6EmH56mkHZ1esxmnlKCaZVpaBIVt4EvXwMkwwV 1pLRj7P3VEUqAVG65EboxO4qcT0A.AciqPt.ozAatiBSco_pyq03Uaasz1cPFBIdB5xsUUjdW605 zKnkHTOS9lQNSUL6QXGboqL8M6oHTyKhzzkk8ATdcdOKLHWXD6hONVOKZmy6vp8X14rmYkBlGXsR bHOF7Qv3T.nG9dnBTsmxVhYPb1hQZnsezloRszhoLB7N16K1wtNbZGHEqIshnzhthRl9f5UR97uy fAIyO9PLwCoFEG9j0PmVk1P_Etv15VrWZr25U6NkHo9wMHBOpzzpY02BubcVRjIpMrw7nai8mUOU 6FIW9nkbE9x5wj7TL7uzvtLWP7Q4CjxbRTlOt7ckZiGQOD.Fpk64StYC6W9_GZD5hdR9gdXcXtmT ltqexgGB3eVJ382vF.1olA79KqztH3C2YLZC7xzqUApnPiFZCg2IRlifyqWkg.g.VrkwX09HRX8v wJWW4GLzPjAsV7dbAJYbdtXEjMoQKTVJ5lUnO6Ddt4Uf3P.kWibBjLVGpDgtOi8GJX1BzwDnvo1n V2vKpF9f.hyE0LL1DI56545RNQPH91hNdYBhlruSlAlmkSiVqeHq9pzRIPm5Lgnhhw2v9Z_w8ulV DcWDfb2ylGZiHCbNtEe4gVJMMP.Z2p1WL.rY2JlQbHYFVOnlGfqlJh_FnwyL1Zq3ibQBWKX9WNoW 90zP58YDlYd9XmHU8uBSlhLVubZ_Lpny4pbUlpn_3GsBPz8a9tNKYJHVddW1s76cOUYeAYMgK8N. smWzDL_VeEc2EZIbdIElLzi4dYOmCCpSEMEI775_HshJXLV6vZgWQcgJYCJEKPcYViwGUq2mcmm7 3khoqkttO0JE02aqcxjc7QLP.mkcWtUWlRWJ2pEpEVvq3oVG96vDiAKWkmEuVILvlPoPi_Xh7ib5 vS0YYeFATCas7zFma5e0ZKTEO4Eoui.BAHTeXgwLA7FpjbDB8PD_VflYRtHEC_thzmPnuRhKyfOm dOQIOxxRMad1u0c.jfR1jwpUllLjFC5O6EmZcxqbjeEfKW6QKPMIZCX54aOsE0xDImhwT8ergT6Y G5ku.stm.k6XR5Rr9CZ6ybs47kM6IlH2XmU5y733yCrhZbvpfzzl6lGAif44pSBr0rqc35XFvR7l Ttrni3BcbVld0UHy2cq3ruh_lwTf.Tm1jNJMjec13hVWnMxndkUVDQrTbu2MgfkrcGgtudMbF_iS WF0AzHmXaexyJTF6sgJx_nZmCTHyzZtczXsXAheU7hBvHARLXEdwIPe15MedLN2ddj3hLK4FlDhS Ee5JCMgs7n2zwlULCp0KtBD2p7iZnBjGDrUySi6c2iAvCU8hdsITMqcLN9SxjV5r022nJ_WlkNnZ wRDQX2bPpz6_OAXzjinscOBph_npGc3tEsYZWM_rTxFmd7Vlgugd3rvJTR8iVVPdApr8UfEqsLmI tf7aUYrT_mpghEBbpDlt6o02Nq6TepNDB3o60m_V.j8QzIMYG1qzFTWyEG7J94yDBNR5c0gzKgab pfimAPNqJ5CJ0WP6xtVhugGpGG1aE7FdtzW5wRNxm4vtghmpcAYd1.PV_kPMmjmH8FSUbaZAP4co muRdN90NFwkEPp9UZrtS3UCoNfoyaerIZX0dzp4fdUc0oBTWI.vkTTAM1mYGqFjgQ4uMMW0YvGiL 8voj2Nlj6hDPtB1dPcbLUeTdFPlcmAnrFWxiu9D.pmLsoYI2CdM6Z9_aRB0H1Di_5b17ldBoCZ8L 4tPDDqpSHW0f8DgmODuNGKFDuhj1z3rKXKmLgP5A6ZIMCAqAgcxTwyXI- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 18 Jan 2021 17:51:43 +0000 Received: by smtp423.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8cef55378b27df9b86ffdc22876e24e7; Mon, 18 Jan 2021 17:51:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> Date: Mon, 18 Jan 2021 09:51:36 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210116043740.GA19523@www.zefox.net> <20210116155538.GA24259@www.zefox.net> <20210116220334.GA26756@www.zefox.net> <20210117174006.GA30728@www.zefox.net> <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DKK9F3Q3Vz4lKP X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.30:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.30:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.30:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 17:51:47 -0000 On 2021-Jan-17, at 19:19, Mark Millard wrote: > On 2021-Jan-17, at 17:50, bob prohaska wrote: >=20 >> On Sun, Jan 17, 2021 at 12:30:51PM -0800, Mark Millard wrote: >>>=20 >>>=20 >>> On 2021-Jan-17, at 09:40, bob prohaska = wrote: >>>=20 >>>> On Sat, Jan 16, 2021 at 03:04:04PM -0800, Mark Millard wrote: >>>>>=20 >>>>> Other than -j1 style builds (or equivalent), one pretty much >>>>> always needs to go looking around for a non-panic failure. It >>>>> is uncommon for all the material to be together in the build >>>>> log in such contexts. >>>>=20 >>>> Running make cleandir twice and restarting -j4 buildworld brought >>>> the process full circle: A silent hang, no debugger response, no >>>> console warnings. That's what sent me down the rabbit hole of make >>>> without clean, which worked at least once... >>>=20 >>> Unfortunately, such a hang tends to mean that log files and such >>> were not completely written out to media. We do not get to see >>> evidence of the actual failure time frame, just somewhat before. >>> (compiler/linker output and such can have the same issues of >>> ending up with incomplete updates.) >>>=20 >>> So, pretty much my notes are unlikely to be strongly tied to >>> any solid evidence: more like alternatives to possibly explore >>> that could be far off the mark. >>>=20 >>> It is not clear if you were using: >>>=20 >>> LDFLAGS.lld+=3D -Wl,--threads=3D1 >>>=20 >>> or some such to limit the multi-thread linking and its memory. >> No, I wasn't trying to limit ld.lld thread number. >=20 > You might want to try a significant change in the memory use > just to see if it makes a difference or not --despite the > extra time. This could included limiting lld thread usage > and limiting to a smaller -jN . >=20 >>> I'll note that if -j4 gets 4 links running in parallel it used >>> to be each could have something like 5 threads active on a 4 >>> core machine, so 20 or so threads. (I've not checked llvm11's >>> lld behavior. It might avoid such for defaults.) >>>=20 >>> You have not reported any testing of -j2 or -j3 so far, just >>> -j4 . (Another way of limiting memory use, power use, temperature, >>> etc. .) >>>=20 >> Not recently, simply because it's so slow to build. On my = "production" >> armv7 machines running stable/12 I do use -j2. But, they get updated >> only a couple times per year, when there's a security issue.=20 >=20 > See the earlier note about possibly deliberate test of > using less memory space. (And more later, below.) >=20 >>> You have not reported if your boot complained about the swap >>> space size or if you have adjusted related settings to make >>> non-default tradeoffs for swap amanagment for these specific >>> tests. I recommend not tailoring and using a swap size total >>> that is somewhat under what starts to complain when there is >>> no tailoring. >>>=20 >> Both Pi2 and Pi3 have been complaining about too much swap >> since I first got them. Near as can be told it's never been >> a demonstrated problem, thus far. Now, as things like LLVM >> get bigger and bigger, it seems possible excess swap might >> cause, or obscure, other problems. For the Pi2 I picked 2 >> GB from the old "2x physical RAM" rule.=20 >=20 > I'd take those warnings as FreeSD reporting that the system is > expected to be in a mistuned configuration by "normal" criteria. > Doing the tuning to allow more swap has the documented tradeoffs: >=20 > kern.maxswzone > . . . >=20 > Note that swap metadata can be fragmented, which means = that > the system can run out of space before it reaches the > theoretical limit. Therefore, care should be taken to = not > configure more swap than approximately half of the > theoretical maximum. >=20 > (The above is what the warning is about. But then there is . . .) >=20 > Running out of space for swap metadata can leave the = system > in an unrecoverable state. Therefore, you should only > change this parameter if you need to greatly extend the = KVM > reservation for other resources such as the buffer = cache or > kern.ipc.nmbclusters. Modifies kernel option > VM_SWZONE_SIZE_MAX. >=20 > (NOTE: That last paragraph is talking about *decreasing* = kern.maxswzone > to get more room for non-swap-managment things in KVM. [Too bad the > wording says "change".] But increasing kern.maxswzone to allow more = swap > leaves less space for the buffer cache or like, making for tradeoffs > being involved.) FYI: I re-established my access to a RPi2B V1.1 and made it report: "maximum recommended amount (468832 pages)" (The figure can vary some from release to release.) 468832*4096 =3D=3D 1920335872 or a little over 1831 MiBytes For the 4096 Byte pages, that means that the following from gpart fits without complaint (size is in blocks, not pages): 413140992 3686400 da0p2 freebsd-swap (1.8G) 3686400*512 is a little over 1.75 GiByte or 1800 MiByte. So I've left some room below 1831 MiBytes, but not a lot. FYI about my build experiment that is running: # sysctl hw.physmem hw.physmem: 979042304 which, in recent times for armv7, I can (and did) set in /boot/loader.conf on a faster cortex-A7 SBC (that can boot the same media but has more RAM). So I tried a -j4 build, but with LDFLAGS.lld+=3D -Wl,--threads=3D1 in use and my other particular src.conf/make.conf like content (so the builds do likely differ from yours in various ways). My build is producing a non-debug build (but with -g symbols). Somewhat after where your buildworld.log stops, my odd variant of top was reporting: Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki = MaxObs(Act+Wir) Swap: . . . , 145832Ki MaxObsUsed and top was also showing lots of processes as having "0B" RES in STATE "wait" or "nanslp" (so, apparently swapped out, not paging). ("MaxObs" is short for "maximum observed".) For comparison, your swapscript.log reported a maximum total of 346192 KiBytes "Used" for swap, about 98% into the log file. (Time goes by . . .) It finished with building libllvm and is part way into building libclang. This is probably well past where your hangup happened, given that your published buildworldlog file stopped with libllvm's Target/ARM/ARMMCInstLower.o . My odd top now shows: Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki = MaxObs(Act+Wir) Swap: . . . , 392328Ki MaxObsUsed The build continues to run. I'll let you know how it goes. >>>> The residue of the top screen shows >>>>=20 >>>> last pid: 63377; load averages: 4.29, 4.18, 4.15 = up 1+07:11:07 04:46:46 >>>> 60 processes: 5 running, 55 sleeping >>>> CPU: 70.7% user, 0.0% nice, 26.5% system, 2.8% interrupt, 0.0% = idle >>>> Mem: 631M Active, 4932K Inact, 92M Laundry, 166M Wired, 98M Buf, = 18M Free >>>> Swap: 2048M Total, 119M Used, 1928M Free, 5% Inuse, 16K In, 3180K = Out >>>> packet_write_wait: Connection to 50.1.20.26 port 22: Broken pipe >>>> bob@raspberrypi:~ $ ssh www.zefox.com RES STATE C TIME = WCPU COMMAND >>>> ssh: connect to host www.zefox.com port 22: Connection timed = out86.17% c++ >>>> bob@raspberrypi:~ $ 1 99 0 277M 231M RUN 0 3:26 = 75.00% c++ >>>> 63245 bob 1 99 0 219M 173M CPU0 0 2:10 = 73.12% c++ >>>> 62690 bob 1 98 0 354M 234M RUN 3 9:42 = 47.06% c++ >>>> 63377 bob 1 30 0 5856K 2808K nanslp 0 0:00 = 3.13% gstat >>>> 38283 bob 1 24 0 5208K 608K wait 2 2:00 = 0.61% sh >>>> 995 bob 1 20 0 6668K 1184K CPU3 3 8:46 = 0.47% top >>>> 990 bob 1 20 0 12M 1060K select 2 0:48 = 0.05% sshd >>>> .... >>>=20 >>> This does not look like ld was in use as of the last top >>> display update's content. But the time between reasonable >>> display updates is fairly long relative to CPU activity >>> so it is only suggestive. >>>=20 >>>> [apologies for typing over the remnants] >>>>=20 >>>> I've put copies of the build and swap logs at >>>>=20 >>>> http://www.zefox.net/~fbsd/rpi2/buildworld/ >>>>=20 >>>> The last vmstat entry (10 second repeat time) reports: >>>> procs memory page disks faults = cpu >>>> r b w avm fre flt re pi po fr sr da0 sd0 in sy = cs us sy id >>>> 4 0 14 969160 91960 685 2 2 1 707 304 0 0 11418 = 692 1273 45 5 50 >>>>=20 >>>> Does that point to the memory exhaustion suggested earlier in the = thread? >>>> At this point /boot/loader.conf contains = vm.pfault_oom_attempts=3D"-1", but=20 >>>> that's a relic of long-ago attempts to use USB flash for root and = swap. >>>> Might removing it stimulate more warning messages? >>>>=20 >>>=20 >>> vm.pfault_oom_attempts=3D"-1" should only be used in contexts where >>> running out of swap will not happen. Otherwise a deadlocked system >>> can result if it does run out of swap. (Run-out has more senses the >>> just the swap partition being fully used: other internal resources >>> for keeping track of the swap can run into its limits.) I've no >>> evidence that the -1 was actually a problem. >>>=20 >>> I do not find any 1000+ ms/w or ms/r figures in swapscript.log . >>> I found 3 examples of a little under 405 (on sdda0*), 3 between >>> 340 and 345 (da0*), 4 in the 200s (da0*), under 60 in the 100s >>> (da0*). It does not look to me like the recorded part had problems >>> with the long latencies that you used to have happen. >>>=20 >>> So I've not found any specific evidence about what led to the >>> hangup. So my earlier questions/suggestions are basically >>> arbitrary and I would not know what to do with any answers >>> to the questions. >>>=20 >>> The only notes that are fairly solid are about the hangup leading >>> to there being some files that were likely incompletely updated >>> (logs, compiler output files, etc.). >>>=20 >>=20 >> The notion that log files might be truncated didn't didn't register=20= >> until you brought it up.=20 >>=20 >> The obvious things to try seem to be: >> Disable vm.pfault_oom_attempts=3D"-1" >> Decrease swap partition size >> Try using WITH_META_MODE >=20 > I'll note that you may well have already spent more time > not getting complete builds than doing one "use less memory" > test would have taken (linker thread count limits, smaller > -jN). To find fairly optimal settings for building on the > RPi2 V1.1, you may have to explore on both sides of the > optimal settings range, just to identify the optimal range > for the settings as being between known bounds. >=20 > Of course, for all I know, the "use less memory" tests might > also fail. If that happened, it would tend to stop spending > time testing configurations even less likely to finish > building. >=20 >> WITH_META_MODE seems relatively easy; just add -DWITH_META_MODE to = the make >> command line for buildworld and add filemon_load=3D"YES" to = boot/loader.conf, >> but I wonder about the burdens it'll impose on CPU and disk = space/throughput.=20 >> There's nothing to lose at this stage, but I'm all ears if there's a = better >> approach. >=20 > You could trade off some I/O by not generating swapscript.log > since it seems to not be of much help for the current issue. >=20 > I'll also note that META_MODE by default does not generate as > much stdout text but stores more across the various .meta files. > So, by default, buildworld.log (by itself) would be much > smaller. (So disabling recording of buildworld.log would not > make much of a difference.) >=20 > I'll remind of the things that are environment-only variables, > including WITH_META_MODE : >=20 > QUOTE > The environment of make(1) for the build can be controlled via the > SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some > examples that may only be set in this file are WITH_DIRDEPS_BUILD, = and > WITH_META_MODE, and MAKEOBJDIRPREFIX as they are environment-only > variables. > END QUOTE >=20 > "may only be set in this file" is false relative to setting the > enviromnent on the command line but true compared to the likes > of putting the text in /etc/src.conf or the like. My script for > building for armv7 in a armv7 context looks something like: >=20 > script = ~/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-armv7-host= -$(date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.armv7-clang-bootstrap.armv7-hos= t" \ > WITH_META_MODE=3Dyes \ > MAKEOBJDIRPREFIX=3D"/usr/obj/armv7_clang/arm.armv7" \ > make $* >=20 > (So I happened to not use -DWITH_META_MODE . The context is > /bin/sh based, by the way.) >=20 > There are contexts for which I control UBLR_LOADADDR via > an additional line in the above, such as: >=20 > WORLD_FLAGS=3D"${WORLD_FLAGS} UBLDR_LOADADDR=3D0x42000000" \ >=20 > (But such is old material that I've not validated as > being needed in even remotely modern times.) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Jan 18 19:07:47 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 758CE4F3645 for ; Mon, 18 Jan 2021 19:07:47 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.160]) (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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DKLry3N7lz4rQP for ; Mon, 18 Jan 2021 19:07:46 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1610996863; s=strato-dkim-0002; d=obsigna.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:From: Subject:Sender; bh=eTi8inKXweXL5wxMFcHzyfbKdOU7DAuKl/5iCE8ecxA=; b=jHtLydPQEBKukBuBykRZI7CLAxNMfqZHNbPuIhkM69bKA9qDK2ln6KR5eyjsat7Yxs rtGDm2X9Vezx5mQfO5DLiqkiLrqj3TNjsKPE0kYx9K14VHOsma/BpGF8esdnPdj5AUJi LztnGPQE/X4J54OoI9BGyN6gKuujTWexIaHi44Is+/0hhi4dKFP6mztrJLI1i7Y9Jzpb hAw1C864TgLz+gwA1/toS9PBdqhOHtL3PtNi6m1RtXsBrIU6MiL0xI0hzJGqTsRN8j/j 24wFfsjXepNpYuvxUUAIgkw3Qvte/eZr9y7fkVbgRWAFfIxbRyIl31bCINw07W2LgkG2 ZxOw== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio0dVVInWnas+zpAhAiA/W" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 47.12.1 DYNA|AUTH) with ESMTPSA id d0872bx0IJ7gn6K (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 18 Jan 2021 20:07:42 +0100 (CET) Received: from rolf-aux.obsigna.com (rolf-aux.obsigna.com [192.168.222.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 0C5FD1350F946; Mon, 18 Jan 2021 16:07:38 -0300 (-03) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: GENERICSD snapshot on a BBB has issues with loading the if_rtwn_usb module From: "Dr. Rolf Jansen" In-Reply-To: <9F0684B2-02EA-4647-BA02-8C6F80C421F7@obsigna.com> Date: Mon, 18 Jan 2021 16:07:38 -0300 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9C2425C5-ABF2-4A3B-8C93-C20554A59000@obsigna.com> References: <47700631-2D94-4BA8-9707-9ADD70C99600@obsigna.com> <20210116184333.f91594f9c3505d2c588d9634@bidouilliste.com> <20210116184833.1a3182a20a2b6c727b64bb59@bidouilliste.com> <06F689CA-B781-4CEB-8F8A-B00FAC684DD3@obsigna.com> <20210117174539.43b55379e6a37881589616a8@bidouilliste.com> <20210117225539.c113796159735c5a3950c774@bidouilliste.com> <03F9A3D3-0A2B-4B09-9C8D-AAAF761C0F4C@obsigna.com> <20210118094510.48eee03d502ea25ab7d09938@bidouilliste.com> <9F0684B2-02EA-4647-BA02-8C6F80C421F7@obsigna.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4DKLry3N7lz4rQP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=obsigna.com header.s=strato-dkim-0002 header.b=jHtLydPQ; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@obsigna.com designates 81.169.146.160 as permitted sender) smtp.mailfrom=freebsd-rj@obsigna.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[obsigna.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[81.169.146.160:from]; ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[obsigna.com:s=strato-dkim-0002]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[obsigna.com]; SPAMHAUS_ZRD(0.00)[81.169.146.160:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[81.169.146.160:from]; FROM_NAME_HAS_TITLE(1.00)[dr]; RWL_MAILSPIKE_POSSIBLE(0.00)[81.169.146.160:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 19:07:47 -0000 > Am 18.01.2021 um 09:02 schrieb Dr. Rolf Jansen = : >=20 >> Am 18.01.2021 um 05:45 schrieb Emmanuel Vadot = : >>=20 >> On Sun, 17 Jan 2021 19:01:24 -0300 >> "Dr. Rolf Jansen" wrote: >>=20 >>>> Am 17.01.2021 um 18:55 schrieb Emmanuel Vadot = : >>>>=20 >>>> On Sun, 17 Jan 2021 18:49:01 -0300 >>>> "Dr. Rolf Jansen" wrote: >>>>=20 >>>>>> Am 17.01.2021 um 13:45 schrieb Emmanuel Vadot = : >>>>>>=20 >>>>>> On Sat, 16 Jan 2021 15:11:28 -0300 >>>>>> "Dr. Rolf Jansen" > wrote: >>>>>>=20 >>>>>>>> Am 16.01.2021 um 14:48 schrieb Emmanuel Vadot = >: >>>>>>>>=20 >>>>>>>> On Sat, 16 Jan 2021 18:43:33 +0100 >>>>>>>> Emmanuel Vadot >> wrote: >>>>>>>>=20 >>>>>>>>> On Sat, 16 Jan 2021 14:08:58 -0300 >>>>>>>>> "Dr. Rolf Jansen" wrote: >>>>>>>>>=20 >>>>>>>>>> I updated one of my BBB from an older 13-CURRENT (July 2020) = to the latest 13-ALPHA1 snapshot from Jan, 14th ? = GENERICSD-20210114-7ae27c2d6c4-255938. >>>>>>>>>>=20 >>>>>>>>>> I had successfully employed an USB-WLAN dongle based on the = RTL8188eu chipset. I only added the following into /boot/loader.conf: >>>>>>>>>>=20 >>>>>>>>>> if_rtwn_usb_load=3D"YES" >>>>>>>>>>=20 >>>>>>>>>> By that all dependend modules were loaded automatically in a = snap. With ALPHA1 this doesn?t work anymore. After hours of = troubleshooting, I got it working by adding the following into = /etc/rc.conf: >>>>>>>>>>=20 >>>>>>>>>> kld_list=3D"if_rtwn_usb" >>>>>>>>>>=20 >>>>>>>>>> The "Loading kernel modules:" takes apprx. 4 seconds, = however, then the USB-WLAN device is enumerated correctly and it is = ready to use. This makes me think that this uncommon huge delay is the = culprit. I checked this with some snapshot thats I had installed = already. The issue seems to have been introduced together with the = switch to GENERICSD. A GENERICSD 13-CURRENT from end of December showed = this issue already, while a BBB-specific snapshot (from November 2020) = that I had installed on another BBB works as before by loading the = modules in /boot/loader.conf. >>>>>>>>>>=20 >>>>>>>>>> I don't mind to load the modules by the way of the kld_list = directive in /etc/rc.conf. However, the unusual long duration of loading = the module and its dependencies might be an indication for a more = fundamental issue. >>>>>>>>>>=20 >>>>>>>>>> Please feel free to ask me for doing more tests.=20 >>>>>>>>>>=20 >>>>>>>>>> Best regards >>>>>>>>>>=20 >>>>>>>>>> Rolf >>>>>>>>>=20 >>>>>>>>> I can reproduce that on my netbooted BBB. >>>>>>>>> The module is correctly loaded : >>>>>>>>>=20 >>>>>>>>> Loading >>>>>>>>> kernel... /boot/kernel/kernel text=3D0x1b4 text=3D0x68d638 = text=3D0x1c84f0 >>>>>>>>> data=3D0xb4070 data=3D0x0+0x258000 = syms=3D[0x4+0xa5ab0+0x4+0x119fd4] Loading >>>>>>>>> configured modules... /boot/kernel/if_rtwn_usb.ko text=3D0xb960 >>>>>>>>> text=3D0x62c0 data=3D0x2cc+0x3b syms=3D[0x4+0x3570+0x4+0x293f] = /boot/entropy >>>>>>>>> size=3D0x1000 /etc/hostid >>>>>>>>> size=3D0x25 Using DTB provided by EFI at >>>>>>>>> 0x87f00000. Kernel entry at >>>>>>>>> 0x96e00200... Kernel args: >>>>>>>>> (null) = =20 >>>>>>>>> ---<>--- = =20 >>>>>>>>>=20 >>>>>>>>> But it isn't loaded anymore after booting : >>>>>>>>> root@bbb:~ # kldstat=20 >>>>>>>>> Id Refs Address Size Name >>>>>>>>> 1 1 0xc0000000 d23a8c kernel >>>>>>>>>=20 >>>>>>>>> I don't think it has to do with the switch to GENERICSD, there = is (at >>>>>>>>> least shouldn't be) any difference between the old BBB image = and the >>>>>>>>> GENERICSD one. >>>>>>>=20 >>>>>>> Yes, this might well be a coincidence. I do neither have the = last BBB specific snapshot nor the first GENERICSD one for testing these = against each other. >>>>>>>=20 >>>>>>>> Just did a test on my OrangePi One (Allwinner H3 armv7 with = 512MB of >>>>>>>> RAM) and this is the same. >>>>>>>> The problem seems to be module dependancy, loader only loads >>>>>>>> if_rtnw_usb but doing a kldload also brings wlan.ko and rtwn.ko >>>>>>>=20 >>>>>>> I can confirm this. And in addition loading the if_rtwn_usb.ko = module and its dependcies manually also takes now significantly longer = compared to a manual load on the BBB specific 13-CURRENT from November. = Perhaps something has been changed in the dependency resolver. >>>>>>>=20 >>>>>>=20 >>>>>> Fixed in 0f2434ea000e >>>>>>=20 >>>>>> Thanks for reporting. >>>>>=20 >>>>> Unfortunately, this did not resolve the issue. I updated my = working copy with git pull and verified that your changes made it into = my source tree. Then I built a new kernel and replaced the original = ALPHA1 kernel from 2021-01-14 by this new one. The rtwn-modules are = still not loaded by the if_rtwn_usb_load=3D"YES" directive in = /boot/loader.conf. >>>>>=20 >>>>> Best regards >>>>>=20 >>>>> Rolf >>>>=20 >>>> You need to update loader.efi on the ESP partition. >>>=20 >>> Please excuse my ignorance. Do I need to build world for this? Then = where is the newly build loader.efi? >>>=20 >>> Best regards >>>=20 >>> Rolf >>=20 >> It's part of buildworld yes but you can rebuild it with : >> (cd stand/ && make buildenv TARGET_ARCH=3Darmv7 BUILDENV_SHELL=3D"make >> clean all -sj4") >>=20 >> Then locate loader_lua.efi in the obj directory and place it in the >> ESP (the fat16/fat32 partition) as efi/boot/bootarm.efi >=20 > This resolved the issue. >=20 > Thank you very much and best regards While loading of kernel modules do work with the newly build = loader_lua.efi, a regression emerged. In /boot/loader.conf I have for = some time now the directive loader_color=3D"NO" in order to prevent the = serial console changes from my default scheme black text on white = background to white on black. Since today, the serial console shows = again everything white on black. Is this directive not functional = anymore? How can I force the serial console keep on showing black text = on white background? Best regards Rolf From owner-freebsd-arm@freebsd.org Mon Jan 18 21:20:57 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 187C44F6093 for ; Mon, 18 Jan 2021 21:20:57 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DKPpb3qgSz3GPr for ; Mon, 18 Jan 2021 21:20:55 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1611004853; 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=KScA9iv2/Bw4UgvGLN32OWMH/knggjBGgmzI5ZuCE4c=; b=QY3XME6shCa+77d3hmOeJUY3fQ/JoPUokOkUCsskUKqYopNxOXkB17Sq3EPYodXvfe7A4Q fJ6iPdqxUxpj2jVHI+Yn9sHOSRhJcb0eVz0DrOPHh4+2bO9pRftoubl49jBIOwgYLwwFs+ T0Iqc219RS+0C0J4i/ZJUmIZyMjWabc= Received: from amy.home (lfbn-idf2-1-745-114.w86-247.abo.wanadoo.fr [86.247.192.114]) by mx.blih.net (OpenSMTPD) with ESMTPSA id d1817f52 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 18 Jan 2021 21:20:53 +0000 (UTC) Date: Mon, 18 Jan 2021 22:20:52 +0100 From: Emmanuel Vadot To: "Dr. Rolf Jansen" Cc: freebsd-arm@freebsd.org Subject: Re: GENERICSD snapshot on a BBB has issues with loading the if_rtwn_usb module Message-Id: <20210118222052.2e0d6c824f0685be8199ad03@bidouilliste.com> In-Reply-To: <9C2425C5-ABF2-4A3B-8C93-C20554A59000@obsigna.com> References: <47700631-2D94-4BA8-9707-9ADD70C99600@obsigna.com> <20210116184333.f91594f9c3505d2c588d9634@bidouilliste.com> <20210116184833.1a3182a20a2b6c727b64bb59@bidouilliste.com> <06F689CA-B781-4CEB-8F8A-B00FAC684DD3@obsigna.com> <20210117174539.43b55379e6a37881589616a8@bidouilliste.com> <20210117225539.c113796159735c5a3950c774@bidouilliste.com> <03F9A3D3-0A2B-4B09-9C8D-AAAF761C0F4C@obsigna.com> <20210118094510.48eee03d502ea25ab7d09938@bidouilliste.com> <9F0684B2-02EA-4647-BA02-8C6F80C421F7@obsigna.com> <9C2425C5-ABF2-4A3B-8C93-C20554A59000@obsigna.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DKPpb3qgSz3GPr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=QY3XME6s; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[212.83.155.74:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.83.155.74:from]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 21:20:57 -0000 On Mon, 18 Jan 2021 16:07:38 -0300 "Dr. Rolf Jansen" wrote: > > Am 18.01.2021 um 09:02 schrieb Dr. Rolf Jansen : > > > >> Am 18.01.2021 um 05:45 schrieb Emmanuel Vadot : > >> > >> On Sun, 17 Jan 2021 19:01:24 -0300 > >> "Dr. Rolf Jansen" wrote: > >> > >>>> Am 17.01.2021 um 18:55 schrieb Emmanuel Vadot : > >>>> > >>>> On Sun, 17 Jan 2021 18:49:01 -0300 > >>>> "Dr. Rolf Jansen" wrote: > >>>> > >>>>>> Am 17.01.2021 um 13:45 schrieb Emmanuel Vadot : > >>>>>> > >>>>>> On Sat, 16 Jan 2021 15:11:28 -0300 > >>>>>> "Dr. Rolf Jansen" > wrote: > >>>>>> > >>>>>>>> Am 16.01.2021 um 14:48 schrieb Emmanuel Vadot >: > >>>>>>>> > >>>>>>>> On Sat, 16 Jan 2021 18:43:33 +0100 > >>>>>>>> Emmanuel Vadot >> wrote: > >>>>>>>> > >>>>>>>>> On Sat, 16 Jan 2021 14:08:58 -0300 > >>>>>>>>> "Dr. Rolf Jansen" wrote: > >>>>>>>>> > >>>>>>>>>> I updated one of my BBB from an older 13-CURRENT (July 2020) to the latest 13-ALPHA1 snapshot from Jan, 14th ? GENERICSD-20210114-7ae27c2d6c4-255938. > >>>>>>>>>> > >>>>>>>>>> I had successfully employed an USB-WLAN dongle based on the RTL8188eu chipset. I only added the following into /boot/loader.conf: > >>>>>>>>>> > >>>>>>>>>> if_rtwn_usb_load="YES" > >>>>>>>>>> > >>>>>>>>>> By that all dependend modules were loaded automatically in a snap. With ALPHA1 this doesn?t work anymore. After hours of troubleshooting, I got it working by adding the following into /etc/rc.conf: > >>>>>>>>>> > >>>>>>>>>> kld_list="if_rtwn_usb" > >>>>>>>>>> > >>>>>>>>>> The "Loading kernel modules:" takes apprx. 4 seconds, however, then the USB-WLAN device is enumerated correctly and it is ready to use. This makes me think that this uncommon huge delay is the culprit. I checked this with some snapshot thats I had installed already. The issue seems to have been introduced together with the switch to GENERICSD. A GENERICSD 13-CURRENT from end of December showed this issue already, while a BBB-specific snapshot (from November 2020) that I had installed on another BBB works as before by loading the modules in /boot/loader.conf. > >>>>>>>>>> > >>>>>>>>>> I don't mind to load the modules by the way of the kld_list directive in /etc/rc.conf. However, the unusual long duration of loading the module and its dependencies might be an indication for a more fundamental issue. > >>>>>>>>>> > >>>>>>>>>> Please feel free to ask me for doing more tests. > >>>>>>>>>> > >>>>>>>>>> Best regards > >>>>>>>>>> > >>>>>>>>>> Rolf > >>>>>>>>> > >>>>>>>>> I can reproduce that on my netbooted BBB. > >>>>>>>>> The module is correctly loaded : > >>>>>>>>> > >>>>>>>>> Loading > >>>>>>>>> kernel... /boot/kernel/kernel text=0x1b4 text=0x68d638 text=0x1c84f0 > >>>>>>>>> data=0xb4070 data=0x0+0x258000 syms=[0x4+0xa5ab0+0x4+0x119fd4] Loading > >>>>>>>>> configured modules... /boot/kernel/if_rtwn_usb.ko text=0xb960 > >>>>>>>>> text=0x62c0 data=0x2cc+0x3b syms=[0x4+0x3570+0x4+0x293f] /boot/entropy > >>>>>>>>> size=0x1000 /etc/hostid > >>>>>>>>> size=0x25 Using DTB provided by EFI at > >>>>>>>>> 0x87f00000. Kernel entry at > >>>>>>>>> 0x96e00200... Kernel args: > >>>>>>>>> (null) > >>>>>>>>> ---<>--- > >>>>>>>>> > >>>>>>>>> But it isn't loaded anymore after booting : > >>>>>>>>> root@bbb:~ # kldstat > >>>>>>>>> Id Refs Address Size Name > >>>>>>>>> 1 1 0xc0000000 d23a8c kernel > >>>>>>>>> > >>>>>>>>> I don't think it has to do with the switch to GENERICSD, there is (at > >>>>>>>>> least shouldn't be) any difference between the old BBB image and the > >>>>>>>>> GENERICSD one. > >>>>>>> > >>>>>>> Yes, this might well be a coincidence. I do neither have the last BBB specific snapshot nor the first GENERICSD one for testing these against each other. > >>>>>>> > >>>>>>>> Just did a test on my OrangePi One (Allwinner H3 armv7 with 512MB of > >>>>>>>> RAM) and this is the same. > >>>>>>>> The problem seems to be module dependancy, loader only loads > >>>>>>>> if_rtnw_usb but doing a kldload also brings wlan.ko and rtwn.ko > >>>>>>> > >>>>>>> I can confirm this. And in addition loading the if_rtwn_usb.ko module and its dependcies manually also takes now significantly longer compared to a manual load on the BBB specific 13-CURRENT from November. Perhaps something has been changed in the dependency resolver. > >>>>>>> > >>>>>> > >>>>>> Fixed in 0f2434ea000e > >>>>>> > >>>>>> Thanks for reporting. > >>>>> > >>>>> Unfortunately, this did not resolve the issue. I updated my working copy with git pull and verified that your changes made it into my source tree. Then I built a new kernel and replaced the original ALPHA1 kernel from 2021-01-14 by this new one. The rtwn-modules are still not loaded by the if_rtwn_usb_load="YES" directive in /boot/loader.conf. > >>>>> > >>>>> Best regards > >>>>> > >>>>> Rolf > >>>> > >>>> You need to update loader.efi on the ESP partition. > >>> > >>> Please excuse my ignorance. Do I need to build world for this? Then where is the newly build loader.efi? > >>> > >>> Best regards > >>> > >>> Rolf > >> > >> It's part of buildworld yes but you can rebuild it with : > >> (cd stand/ && make buildenv TARGET_ARCH=armv7 BUILDENV_SHELL="make > >> clean all -sj4") > >> > >> Then locate loader_lua.efi in the obj directory and place it in the > >> ESP (the fat16/fat32 partition) as efi/boot/bootarm.efi > > > > This resolved the issue. > > > > Thank you very much and best regards > > While loading of kernel modules do work with the newly build loader_lua.efi, a regression emerged. In /boot/loader.conf I have for some time now the directive loader_color="NO" in order to prevent the serial console changes from my default scheme black text on white background to white on black. Since today, the serial console shows again everything white on black. Is this directive not functional anymore? How can I force the serial console keep on showing black text on white background? > > Best regards > > Rolf Yes we compile with TERM_EMU now so you might need to adjust teken.bg_color and teken.bg_color in loader.conf I think -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Jan 19 03:19:49 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4907F4E1FD4 for ; Tue, 19 Jan 2021 03:19:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DKYmh1CkSz4R3y for ; Tue, 19 Jan 2021 03:19:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611026385; bh=yFXLIUsI8eX/uN6ZMXfmpHOdRa+4/k+Twd4V7vESv3u=; h=Subject:From:Date:To:From:Subject:Reply-To; b=jZEvyuzRBiHME1p00S/jAnlWUgELSnHZiqgcrxhqlmyDLw28mLw3pzisWfbjtuhzgBHTpgoRfApzH9EEYfWrpMjnv2Lewx9VFuihI80e/oga/aFpyfVES9vLKw31LfBooYr1gIHEkRyjE/tccE2d4OQTA22DkF2opOjUIiXOcm1i9oQdgbhWW2XTyDt3ZyqIAiJ6j71EzO2UTKEVJqm6X34rv1R8KDVztHAsbYO3DLzKVGAkJc5PodMU8F7vbpFdBo3RFeuN+6F8aQBGNOvRiJhavvnWtjB1go3/ESXxrwsN1xiLFK7+OJdZ7tp4nRwoeo0p2hFizmkGjhWFHZlnOQ== X-YMail-OSG: R8DN1hcVM1mM_dB1GYazaGsv05kQAcPIGspj6HGj8xQ8ZuRGKXNWemLS3HDVy6N N1uQPBvIGUy61IC8R7zolbJfaf_YANGZzTUPEGbKfTeYtqmuePdJisQ0rQtsFEukznRiezdO.Cow SysPt9gjhMCwFLDjT97HlAwtKyX7xLVM0WT6ZewYQ1blICbMVIewdggIDeNU0nhWiPLY_Vul99wf FCs4m252QLB9Xj0z.jAjx6hcjIj94FrvwlHb_yTHRlCpnAXB.M6kmsIQxEiJ.K2stzM8_zn_HPH_ VdHgI97oYfvvWETfjHYUtBaqYYagkOBvtlGxSfXtppbF.tu6S9lzRpcyvQVYyeaXVSZV9cV92c9l 6abd0lPueupYkdvjRdIscUeykTGeRJXKA2pvtu2DAhSmyT_aFf9LLDLhimOnoe5J83dkIMV4vdMH rbS1F.aQdmpHnEMBjyE.oiA1Wezjg3UZpPxjjRgDeiMsDhld6fJYYkmykBfXKzHPE5ABQVuXPVRE CjKScpKyvlK8CSqa71iwrS9TgCvkQGQE5H3EvjsUDHDWDQJY.NgC0PvyoH54OL2aarLw1YurpRMV WrTs65yj.BakKZvX3Slb9l5O2liVD_8G4Ujb7p48yNBKIYFzvZArjwG06K1RsiTDM.AL3Yhv5eDe Jg3MDv7QSTD61dYyDnCHSg5JYTr25T8429gRIDUlug.3uIJfLqu1iK205C0sK61ma_vwcLGRQQhr 3YIB2pxszVQE3Bhnqw4ab1surbTqwjY1cFQAzvtZFO7ttCRiLSDQxVpurTGRBppHhiDnfIcwKtta Z87gqGp9FifGp.KV9Sj4xf_61Lsj0ZGS4HZoQqfVy3_0Y5RBQU.0TQro_VEcYsrrXk65jk8qrmkc _bX1tmpNfZDWGwcjnGIIcwT.Qecz3qznqkVH58FRyYp9Tz3ml.tSrFzoPIwXHvYS4.QqnYerHgB2 hMrXoDlansOwGhWvtnaxeqDylORYdAxKqqNv6S_WPtp..WRVBHwCi7ZrqcvwuZ6mewclJ0KAqFMS _7qVchXUGYdjKJgdnfu9ryq3xqGQwx9nZJQfO4KgapMYxrZH.0WyVWdNT2XvBnwY0loFqaQqKBoI RXtaBne4RVnaBJ6.vpKTjyXCGd2y0ZYNa9gkPMSUIMcxAY2p4xIe8_xsUipuKfHp7ZF4ow9kAg4B z6PD_vdxaUUT3NbYkfZqczLphMAsjCriTcszbc1HTfW_pYgB5kP6u2J4ln64F2mr4r4GwMuAAi2K 0JlnLV2m8q17wJyBJb8Yh33LWr0VBDHQ.ES_wDsreOrO8fHFM9lRMsEnufRZ62kZ4ChruqBAFI6y 5._p6A5Et7pUgReHZ5FLOIu5ryCF1whUBzYrRu6B4ukz2RWK0WJJkDErkiGDilZTBaZQr3s7eRwU oKiYu08A8gPoTQpDme1I.yoOyWK9SCSzSjlJdHtLsDSZhL2o1L_RIuTM_wIAJ61N0WBMCaqZT6uK OimzlGGEWdMpHpd_oJG8g1vrV0zCL5DQ5.bQatj2wHYN0Yiblu9MVMdXlqRo2pfcISAwDZXREAQn iC8g_ssfViFRgVTvvyqRj.oCp7mMPIwMG6fADvTxmNJj8Sx0_BIv7f0gTl1zInxMjvyejfEvuROG _y4BoIh3aSiJA61fR6T5Y7nbNUXIls8ih4pUb19c15nyDBfcVcsaISs_AJIKmA4nxo2bOTkNv6wl XQj_47OVzUJRpbaJQ5UbRT_f41q6v4_.oHHXLaf2ZoqjKRaAOgz3LtKYVdmC2SIC2nFzlAbPg4Cm mm8E7LBGBUt3a.WtRlepK9InC.Xa2M9C9TRMn273IK7qz9iuHp8WnYOnhdQa96dCs_SiamGhA7.3 BJruE8qegx.lOypSnm32V0mUqJueNK7yeF5G3pgbO9lXbN3vohefToZr5BJkSIfMYXXZI6Z3J1GC Ei0SAZ2aPxlGsA1SjjnlYhdHdKBqBNPSGEsEUnq6ed1j.wfQ5R9tYvdL6LdGxK_kGjK1iENlpPGp c4w6DrbbX.4wt3lyAP8Sgcm06X4v1OFCywk1DCrkn3vnm47hjMZqFwBZc8HCinuFopJ_IUqG6qM. shAs5gNLmOBdyRN3qmMGsQSWFW6rm0yjB6gK4jTbkqZ.WMVw57wIMxuQ9XBE7W60hIWnjcpWSm8F OAdEFORIVLaEEQASVlE1pzqBjLJ7TG4bkC3XF1tNog5v13pv0rZ42cXTrLbhPHOlfDbSIkx6Cap2 jB5m_vhDeAKWMXcGvSQhogMvB.gtDonql3QI2ERRgwgemDK3u9iHPNnBhUNyb6xYv4AmLoze0PTN cveYi2XKh0001putGTyxLZeGi_pCqy3D6oJbuUX_QBzMr38K3wS.PVlS4Z9_38Mrg.t20g7wMGMG 4PhoAw9FdBFcBy3szmGnBTxvL0dSxoTtdyrHWd.cv5A5exZ4Qxs_NltzOPr57XxSQXqzdASe.iGu lyS0vT5Js7zquvMnGHfbreHW0Nnf1tDBeflont_W0EvgagSxEpd5CTL5vSLto4KzAVfs3hGwV5gp kqbwJcGXHQYJt92yLqSI6GzhxY9b0uOaA6F6G8wGDaLOtz6IGw3_V.yRZ6LBffKLBTYzBGY_uoTl lWcvq.lB8dSlsMToiFB.pjWNkshyYkvB8N1WqT4hZXng.zpUIxwHMjO.E.FM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Tue, 19 Jan 2021 03:19:45 +0000 Received: by smtp423.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 026f41280f733af56340d295a8697653; Tue, 19 Jan 2021 03:19:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: Date: Mon, 18 Jan 2021 19:19:40 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> References: <20210116043740.GA19523@www.zefox.net> <20210116155538.GA24259@www.zefox.net> <20210116220334.GA26756@www.zefox.net> <20210117174006.GA30728@www.zefox.net> <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DKYmh1CkSz4R3y X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 03:19:49 -0000 > . . . > FYI: I re-established my access to a RPi2B V1.1 and made > it report: "maximum recommended amount (468832 pages)" >=20 > (The figure can vary some from release to release.) >=20 > 468832*4096 =3D=3D 1920335872 or a little over 1831 MiBytes >=20 > For the 4096 Byte pages, that means that the following from > gpart fits without complaint (size is in blocks, not pages): >=20 > 413140992 3686400 da0p2 freebsd-swap (1.8G) >=20 > 3686400*512 is a little over 1.75 GiByte or 1800 MiByte. So > I've left some room below 1831 MiBytes, but not a lot. >=20 > FYI about my build experiment that is running: >=20 > # sysctl hw.physmem > hw.physmem: 979042304 >=20 > which, in recent times for armv7, I can (and did) set in > /boot/loader.conf on a faster cortex-A7 SBC (that can boot > the same media but has more RAM). >=20 > So I tried a -j4 build, but with LDFLAGS.lld+=3D -Wl,--threads=3D1 > in use and my other particular src.conf/make.conf like content > (so the builds do likely differ from yours in various ways). > My build is producing a non-debug build (but with -g symbols). > Somewhat after where your buildworld.log stops, my odd variant > of top was reporting: >=20 > Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki = MaxObs(Act+Wir) > Swap: . . . , 145832Ki MaxObsUsed >=20 > and top was also showing lots of processes as having "0B" RES > in STATE "wait" or "nanslp" (so, apparently swapped out, not paging). > ("MaxObs" is short for "maximum observed".) >=20 > For comparison, your swapscript.log reported a maximum total of > 346192 KiBytes "Used" for swap, about 98% into the log file. >=20 > (Time goes by . . .) >=20 > It finished with building libllvm and is part way into building > libclang. This is probably well past where your hangup happened, > given that your published buildworldlog file stopped with > libllvm's Target/ARM/ARMMCInstLower.o . My odd top now shows: >=20 > Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki = MaxObs(Act+Wir) > Swap: . . . , 392328Ki MaxObsUsed >=20 > The build continues to run. I'll let you know how it goes. > . . . Just after libclang finished my odd top showed: Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892736Ki = MaxObs(Act+Wir) Swap: . . . , 537588Ki MaxObsUsed After liblldb: Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 899276Ki = MaxObs(Act+Wir) Swap: . . . , 537588Ki MaxObsUsed Much later, after the lldb program had been built: Mem: . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki = MaxObs(Act+Wir) Swap: . . . , 537588Ki MaxObsUsed >>> World build completed on Mon Jan 18 19:10:08 PST 2021 >>> World built in 72960 seconds, ncpu: 4, make -j4 This was building from scratch what was already installed: # ~/fbsd-based-on-what-freebsd-main.sh=20 merge-base: 818390ce0ca539300dd15d7a817784f1e3f7a9b8 merge-base: CommitDate: 2021-01-13 21:27:44 +0000 4180404713ec (HEAD -> mm-src) mm-src snapshot for mm's patched build in = git context. 818390ce0ca5 (freebsd/main, freebsd/HEAD, pure-src, main) arm64: fix = early devmap assertion FreeBSD OPiP2E_RPi2v11 13.0-CURRENT FreeBSD 13.0-CURRENT = mm-src-c255938-g4180404713ec GENERIC-NODBG arm armv7 1300135 1300135 This suggests that you should be able to build on the RPi2B v1.1, using -j4, with appropriate configuration for what and how to build. It is now building the matching kernel, my GENERIC-NODBG style. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jan 19 05:13:01 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 03B534E609B for ; Tue, 19 Jan 2021 05:13:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DKcH66Cnnz4bQn for ; Tue, 19 Jan 2021 05:12:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611033166; bh=71ym+CwJ0Xy40YBornWgs7rKnILinxCHGxAk9dmVSS0=; h=Subject:From:Date:To:From:Subject:Reply-To; b=JVqa21Jzd9QbU6tFQXfCsdXR0LSLVsavr5d8EQH8QiWfrORCUqfoyZZLrVytrF+RS1g5toSDY/aWJOAZVGU6Mzl9UIpdy4m1a52Zaz3FXcuPKNcVi88cMKQFRaSzofo34vaND+fjXNMS1fYLHNjCJieA4XuaTCpirrbHZzcZoY9Pf4aAoZw2LmqcrgsNusCcUDh19e1sWlKvd7IPPh2hF5rWlFVC/suVG2xIMay4Lzay2b8jrKsv7OB3UPCCsyLBxICidrqE5a0QIys6iE0Lb8DS8TIlJTioib12U5+esHM7fDwGKZbYgGIu37tKNrG8JEPYBd38OOAlVDXXJvPgDg== X-YMail-OSG: D2TtJqkVM1nlN8VttsSHAnzth5gh_0QgFXmTgf24MUVTINFIA0rzvIEoMIYJwEp LlRLeUfLbJ8Zke9TJ0KwJg4d5CgkNyBejvfyazV4rmXeU9zuxjA7U_svDS1Z_s2jMx.3uaFWw2he qMEZzyvLgTdx.augUm6Vws5Rhws3D5COeqdWtGtuJmMLlyryP6T.AeKBIPD1orBzz0vCuPzT.C__ 0bcA820XOif3HE.TwtyUduHVxQfgHNZabhwcn5zxsj7zvk4Od4gDHVo8t28C2NPrS8_eazHY643W Mu6GHDQ5VQsU7qlbgoemLwQuJU871En1IAXXeSWbFLMPeWMBDBVr1aM8.XgDGLY.B_rNWHNIRCPF RgT5AFmUyYmUvXe8XG3kyn_xj7aXJ8_1qnHkFGy5.d8VbQZ_JOv1MhB9OTzxOUX0dG_UtxJwN_zD EOnz0Qhi17GPsOLp7Kx1j299cIzQAREr9awim9.LLy_fATps7R1UbadQ3HTA6g9IadCoT.aVq7VD yOeupIWzB2ru0TWeHON.AkqxqkzhaTJ69Q2KjZKLekdJHrWH.QZHuVYmv3NzZIbYzZMtaumpNZ00 G.p6bqLY6TKyzJ2UrctvBoWDVmnEJcZAmVKKd4li5pLeBXHPzNe3wXzlcUXbtO9xksJUyEJLdr_4 i42h3W.Ws8ZhB9xNi5gsS6DmM8L0ko12ECZGONi5cL3IYvyMG4IwxBiPMLyE9zytYolcQRB24Z6G LRPjQ_Ox5mD7s3z499X6ayE21HAYpblTA3gx3jo9XhPtn1VeFV1igMgHaeACZk0kc6mDRQ8XeAB9 6gHkuzvNgWtnqxQwClkXofFoLlnI09Upm0xyiBqPRDWVstC1ba5OvyY.goDP5KP4qNlTrI66HoA6 3bpOOPPaLtvIUGbaU.AdezSNjIMLUm9l1qZlHC3Jwt5IucUzLLE9Pt1R.DfT7Tm6fwKyEiKD6Vgx .x3j530iuta1xYvDPlf6gO_79s1b.897V1o3udOjB97w2ABRq3zqUY6pqHjl3c.JV4_SLacPfcaA QjI5JO9B7wbdJfzdqk._CvAONCOO_1__ZzlsFslrw_CJlUHjwV4rTbnorjR_JkADnRC_P34SzFyq QiIRPPE0HFZwhWeoWx90XeHCZwCUktkfNlKn.aGMEPdermngEshx5V3yLy.2AuH0HhnkAreHqVxk OA1awWuzaVc24ibs_zlEcaqoGuyQENpSEYES1.jzyNi6rMai09rOVDnFYOUBJos82HPQCMMy9rSu hxtHMgWJ.GOuuJDelu9SlI7if.ZGGzx3.g0214mtyKZt0z7aC5cGly2EI9LPwAeFGh62UolIdLzi u3tnJTgTkTkKdGX7.WoCVp_dilLr4FngSQ43xijeQtsx6Fwh6axGJ15rokItD1InrbpK_DYBFAmK LEW2YlO10zeTA83wsvToHw0_0T0E7ffZWSGiiEmYTdyx6QT6.Gl1Z9.2u3AdxtRzDq.TbhQ7LghT efl0yPaQvDJfh6C07lDLKyFcMap7t.OAOoC3OrwLV0jWZpev90a4DDaPwYTgzlf0eQTlhDG1PDwH ajPZLET2EjefzfIfO5BfdIglqZu9E9yzqTHV_IJN8Al7xg0bn54Nzcea6LJMfXr2g.KhifkCZorP O04BQeykGwVz2x0hFqEiOuaHaLplMMg4mgSQzbqaYKJiio4HLVUMyHJiuELNn4QjT.2EEL76_qPc SEhAsYwUlGYwj3xwACqCj5oRzFoHI77EU5rSZw24KNSPhh1rybG.E41K6T9wpM14RHTQtirA2MwR yVToWh1BFvSo.5q1y_nmZZZpK1V5EgGCl1tSd5yr3.JFOAcye9oZzVLIUvFnfD.Gqu35F._tA8wg 72rginYleNKuxIwTFAgOJ9NEOwkW0OLIQ.Uteu7XkJWtEj7Nd9OHPc9a0b9VcgPJhU7yRbAdM93y DNIe75ZCOKqElA2vf4EV4lHNVJe7fhYKTHASKJig6hKW5rdSijOE8a9HFn._Gqlb0.99WKP18UYf Xy8BZTmB7U4WpLuP91Z1y4ZzCA7X8fbpIp2foQtIHnyef0W_zBhRP9PZ2MKV1al77fPfxlmfBwUj LFD.AKilwKtZJDjdqF5r7LSbTWZtmMN3GRcPGWvG3Vpr.Px5_ooIXpubPKdwvBsHzEpIhB1rAXmO XHLNLjRKdUmCTtqFSl1cj0nGuuZXBBQ.Znf04ykzIrcgsjeZNbOXEC5FsSpvveOuNkRBhWJWI7oV TBg3JiOT9pWBpoDRP35rVnthzCfr1dwbhOrnQWRb3Y6BdoaJjhn5Ky8ZuIb78I1CUxVXrhOfb5K7 v74RX.qVZsJB_717JWIzaVAIn7eJkg3mpWqHDJjov1hYASA91XGd9cDAPQhHRfde2Y9cGgwmkLHb lsA5cwkUkEX_yK6qoi8NFHheZu2PZXq4auNbykkVOf8qOfzx1l3YbDfKKMUVxb.2kCdaF8qKShDY xweqaoSVa_ZzQAGJpKHYaOE9nHh1X_MMJrISWYdbP9_rcMURGAr0eAl.EF6OPm7LU3sSBkSslE.o Fag1PgcA93TcqZ59mkXv.1iMm3a2Ktlngkr.31s3Pi3qzGKfJ0XMfVEXL2gKdMQ1i7sw67Tlmkvi 3UtG0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 19 Jan 2021 05:12:46 +0000 Received: by smtp416.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 72328f8d3653c35cee212499c9c77b5e; Tue, 19 Jan 2021 05:12:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> Date: Mon, 18 Jan 2021 21:12:43 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210116043740.GA19523@www.zefox.net> <20210116155538.GA24259@www.zefox.net> <20210116220334.GA26756@www.zefox.net> <20210117174006.GA30728@www.zefox.net> <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DKcH66Cnnz4bQn X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.66.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.66.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 05:13:01 -0000 On 2021-Jan-18, at 19:19, Mark Millard wrote: > . . . >> FYI: I re-established my access to a RPi2B V1.1 and made >> it report: "maximum recommended amount (468832 pages)" >>=20 >> (The figure can vary some from release to release.) >>=20 >> 468832*4096 =3D=3D 1920335872 or a little over 1831 MiBytes >>=20 >> For the 4096 Byte pages, that means that the following from >> gpart fits without complaint (size is in blocks, not pages): >>=20 >> 413140992 3686400 da0p2 freebsd-swap (1.8G) >>=20 >> 3686400*512 is a little over 1.75 GiByte or 1800 MiByte. So >> I've left some room below 1831 MiBytes, but not a lot. >>=20 >> FYI about my build experiment that is running: >>=20 >> # sysctl hw.physmem >> hw.physmem: 979042304 >>=20 >> which, in recent times for armv7, I can (and did) set in >> /boot/loader.conf on a faster cortex-A7 SBC (that can boot >> the same media but has more RAM). >>=20 >> So I tried a -j4 build, but with LDFLAGS.lld+=3D -Wl,--threads=3D1 >> in use and my other particular src.conf/make.conf like content >> (so the builds do likely differ from yours in various ways). >> My build is producing a non-debug build (but with -g symbols). >> Somewhat after where your buildworld.log stops, my odd variant >> of top was reporting: >>=20 >> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki = MaxObs(Act+Wir) >> Swap: . . . , 145832Ki MaxObsUsed >>=20 >> and top was also showing lots of processes as having "0B" RES >> in STATE "wait" or "nanslp" (so, apparently swapped out, not paging). >> ("MaxObs" is short for "maximum observed".) >>=20 >> For comparison, your swapscript.log reported a maximum total of >> 346192 KiBytes "Used" for swap, about 98% into the log file. >>=20 >> (Time goes by . . .) >>=20 >> It finished with building libllvm and is part way into building >> libclang. This is probably well past where your hangup happened, >> given that your published buildworldlog file stopped with >> libllvm's Target/ARM/ARMMCInstLower.o . My odd top now shows: >>=20 >> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki = MaxObs(Act+Wir) >> Swap: . . . , 392328Ki MaxObsUsed >>=20 >> The build continues to run. I'll let you know how it goes. >> . . . >=20 > Just after libclang finished my odd top showed: >=20 > Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892736Ki = MaxObs(Act+Wir) > Swap: . . . , 537588Ki MaxObsUsed >=20 > After liblldb: >=20 > Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 899276Ki = MaxObs(Act+Wir) > Swap: . . . , 537588Ki MaxObsUsed >=20 > Much later, after the lldb program had been built: >=20 > Mem: . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki = MaxObs(Act+Wir) > Swap: . . . , 537588Ki MaxObsUsed >=20 >>>> World build completed on Mon Jan 18 19:10:08 PST 2021 >>>> World built in 72960 seconds, ncpu: 4, make -j4 >=20 > This was building from scratch what was already installed: >=20 > # ~/fbsd-based-on-what-freebsd-main.sh=20 > merge-base: 818390ce0ca539300dd15d7a817784f1e3f7a9b8 > merge-base: CommitDate: 2021-01-13 21:27:44 +0000 > 4180404713ec (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. > 818390ce0ca5 (freebsd/main, freebsd/HEAD, pure-src, main) arm64: fix = early devmap assertion > FreeBSD OPiP2E_RPi2v11 13.0-CURRENT FreeBSD 13.0-CURRENT = mm-src-c255938-g4180404713ec GENERIC-NODBG arm armv7 1300135 1300135 >=20 > This suggests that you should be able to build on the RPi2B v1.1, > using -j4, with appropriate configuration for what and how to build. >=20 >=20 > It is now building the matching kernel, my GENERIC-NODBG style. Done: >>> Kernel build for GENERIC-NODBG completed on Mon Jan 18 20:33:26 PST = 2021 >>> Kernel(s) GENERIC-NODBG built in 4998 seconds, ncpu: 4, make -j4 So, World+Kernel in somewhat under 22 hours. The "MaxObs*" figures were unchanged, so: Mem: . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki = MaxObs(Act+Wir) Swap: . . . , 537588Ki MaxObsUsed This suggests that, for now, 800 MiByte of swap would be something more than 1.5 times what it actually used and 1050 MiBytes would be something like 2.0 times what it actually used, so leaving some notable margin for variations in peek usage, at least when linker threading is avoided. As for what I used to control "what and how to build" . . . # more = ~/sys_build_scripts.armv7-host/make_armv7_nodebug_clang_bootstrap-armv7-ho= st.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-armv7-host= -$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.armv7-clang-bootstrap.armv7-hos= t" \ WITH_META_MODE=3Dyes \ WORLD_FLAGS=3D"${WORLD_FLAGS} UBLDR_LOADADDR=3D0x42000000" \ MAKEOBJDIRPREFIX=3D"/usr/obj/armv7_clang/arm.armv7" \ make $* (In my context, UBLDR_LOADADDR is ignored by anything that can not use the figure given. So I've no bothered to be more selective about having it in the armv7 builds.) # more ~/src.configs/make.conf LDFLAGS.lld+=3D -Wl,--threads=3D1 # more ~/src.configs/src.conf.armv7-clang-bootstrap.armv7-host TO_TYPE=3Darmv7 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D WITH_SYSTEM_LINKER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D #Disables avoiding bootstrap: WITHOUT_LLVM_TARGET_ALL=3D WITHOUT_LLVM_TARGET_AARCH64=3D WITH_LLVM_TARGET_ARM=3D WITHOUT_LLVM_TARGET_MIPS=3D WITHOUT_LLVM_TARGET_POWERPC=3D WITHOUT_LLVM_TARGET_RISCV=3D WITHOUT_LLVM_TARGET_X86=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITHOUT_BINUTILS=3D # WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # # WITHOUT_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D WITH_MALLOC_PRODUCTION=3D WITHOUT_ASSERT_DEBUG=3D WITHOUT_LLVM_ASSERTIONS=3D # # Avoid stripping but do not control host -g status as well: DEBUG_FLAGS+=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # Use of the .clang 's here avoids # interfering with other CFLAGS # usage, such as ?=3D usage. CFLAGS.clang+=3D -mcpu=3Dcortex-a7 CXXFLAGS.clang+=3D -mcpu=3Dcortex-a7 CPPFLAGS.clang+=3D -mcpu=3Dcortex-a7 (I do not claim that you would want WITH_REPRODUCIBLE_BUILD . I just happen to have been experimenting with it. You might not want to be explicit about the cpu to target. You might not want WITH_CLANG_EXTRAS .) # more /usr/fbsd/mm-src/sys/arm/conf/GENERIC-NODBG include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options AUDIT # Not enabled by default in = armv7/v6 kernels # Enabled here to allow kyua = test runs to # possibly report auditing = works. options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT=3D0 # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE options ALT_BREAK_TO_DEBUGGER # Enter debugger on keyboard = escape sequence options KLD_DEBUG #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DEADLKRES # Enable the deadlock resolver nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions DIAGNOSTIC nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING nooptions USB_DEBUG nooptions USB_REQ_DEBUG nooptions USB_VERBOSE The /boot/loader.conf file and the /etc/sysctl.conf files both contained: vm.pageout_oom_seq=3D120 vm.pfault_oom_attempts=3D-1 (The hw.physmem=3D979042304 in /boot/loader.conf was very-special, to better approximate your environment. I also controlled the cpu frequency used via a line in /etc/sysctl.conf . I do not bother with such non-default frequency usage [or related settings] for RPi*'s with the pre-RPi4B style power connections but do control the frequency for the OPi+2E.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jan 20 01:42:28 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 349CE4E56DC for ; Wed, 20 Jan 2021 01:42:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DL7Yt2dh6z3H30 for ; Wed, 20 Jan 2021 01:42:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611106944; bh=KFPXpALPxR/GAi5tkYuVizVV/DP6N2LVmO92bloGEu7=; h=Subject:From:Date:To:From:Subject:Reply-To; b=oys/EgIvY06uJ3Pf2JfKLPFTcz7ejFxDwPyaXhGnZAUBT1mPldVZykadHdo+/n1ImA0I0yycXMVTl+omhGAJslQjJjlBRlOm/iBbsJoSi+CE02DPYn47coeuf2dxe0z2C+KsiRPaf4ByCydVzj54kZhfqfXy5RdqzzKVWwq0KFyr3V/6WfOD70sXkL88ypKhFd4PPx62i3hppdGe2tb0/5ys/9MiNHrsP5dryxIPnK/Kumt9QCzIKhaGVvuocAfu0gVvZp29fFT6cOzJFMO879MEYH7YCqNiyZeNTiJEeX4vBMHEgAOIest1B93AYCYQ3zHzguCyCLXgN1a3fT5IMQ== X-YMail-OSG: iHSptXsVM1mVwaFY.D9rVclZJSU8HiWlxzLa57yRvQKdv2CxorzuefYXjnmBMLH LEmApRaNCJUSQ.o1W0IMiadeQbmnDC18kyiTYY3qG1AzoPdcAyYM16f7N.IBSE8DdJMCzkksNooi .zAs.fKL.9Kp3ZGmQVD5y3WUJMylIzkJgkAmZ_pNgFoQF5imI5O.gIAFvBe4CMFdH2WSMrjgFiJY 3ZZQUP1lPWKVA8s7hhSmI.N6L6KNafU0HwPsHRXeqPr3Rl5XA43ZwyW81OW9LEGdbyDAwkHZY9HF aM_NTPWl_wWa70jyAd9CK7HS4JLlmPtIvCs8.Jmwb2ESHPvzI31i4cJLQ4Sw7ffSQvtwN_JPtNIq ocEkGEIUE29BFJil08dNJhcPMAuuS8HV.G5n2fBP4PdqllesJ9ANndn3SPE_OrlcC0DsZnztN_Bu SPxV_JTrwTj.Q1AZToE_XsUDmf7AS3T32pr3OIJ9RZqxOMArEf2kfIjSOzPxunAzt9rhhiG0pjZD qjnqpZX.xxPI7Gjj1fOU9SlXq9jZYwIkv5BejKj6MNn80HKkxfhmMT2Q1tPIiD8UQG58qKPm2mJc bIMEkQ_z8T4gzJImqTq52HkMStQMHBKg_v8Pj42qCLNtSvglp2982495NXcEuJZ7k1SKAIs7lYPQ JhDqL6Gc5ar06v7PO8f2dq92LdoxkcfEckbDLQJ6eqDOnC2yCyW3bua469rhrW8vtdCyfxYWnsph 52WgW2Mm.z7ymf4wnWRY4pfO8D42Lz89nP1kQACzfLW.sh_zNyZlDCr6MKDL8BM3vLD0mvaamwbi REU1T0Xt9eVd6gLQ30xeRNsF0U9PUFz5KzTi.g.1cKLet9Uz6VxjckZ4L1844Wf0nHau0s2OVzf8 uoI4NvKfqPR3IMAO2i4BIZTnqcY2syjowsQKKlhcGSOD1zJ9bA8kp8vkK8WzkUnKt6_1AKZt_QGN mPhwEU6hBzY43zCe31PWigJVhQouw1arJXaMfPsvfL1NEa1m8KyGyJKbiJ1JP6nDVXmKfPvgiSeA oha9RF85YntQWVDSb9vBmT34UXeScn2CEHgpI7Zi96cQOzXY4q7RNHRAlrBCvqP9afITL4mKAXSP PJ3weSRzUJ0xsd.XKuVnc6UJ9eIT6Zw6WdJ0AIP_T7gVniYSsh1nOXA5W.5C0ZA9hBQCieayiWja JhoTLAjtjYNuVx7d_PC0VrLo5pcIyf92oLGCluQ9ywjnk_5Xt0IGze4JSNqPTn2Am6mIbarx.V01 Li7Tr1ufc8cOgBIGbDhGIN9nIHLKu8YVn__6jdc8JF96qXznjjlUT49i.9std4wF5YZP7DQL0Fwe KoImymLPININSyWUo.aZ_mIYQkb02Fa19LTHJVlQX4iBbUPvlEvqzbJnRatgFgnIwAKhBaCnzqZq euC59Md.SsnOdpMmmO1Il5.3DSo0gWSBT2drcmwJIlSdKbcl_KwywUe1YIqLmXOVsT0Z1Ox1VRgx y3F9pPN3XFQf2rhsTcUJ0f.T2tiK73JofypPOay7mET3AHFmaCs.vks.G26_itwA99LEuJkE1rJd I4b1Jf0Hbhf4QIuU839hPYUQkfhcZBR3JYqiSWG9fOa5a5LRwvyYxUBlHSeV39lYXXnGeZnWs.8. b6NEfe5mN_F8YBZj6tQQnI8SUa9mc53m.0S2bQiIT7k5ZbWAGY3QYxeCDe7mA9zP1fDIu.26SyOq wf8NZ5ba_g4JaMQRzS2gldJMK3FiwDDNZizFtoihHzOd5fnmTw2dKTXovao4fYKhoQNmnExUxY4V lybGwwL7ROzzBNsZkaFLAgXnTPQTOOqmbP12lKk4_FZdgJHGSBC8utVFtDhKIaDuntr5dcCXmUnB oj4zVISkgLrK360xcfNxJBM8LD8v9RUBCtBpQjNGQR1SN45_TzTVRhXKZ3tNkSvbskJrtvPCfsmN DNKfb_QHOGgREfWqLF9LGZkQ.e3OHSfz0AhGvkB_Tc0XZ.TPAgIQDdUtWHs4JCx48wGvy64gNmHO jgpXMXxxf5RqFRTF1hoD5HpS6Z8XEkgpjQ09WJ4tA1z1ZY1s9No_G2rvJuUbmgYTO2FwV9g9fhsH MyMGwNcGP5Qjn_91DHndR7gc7LFC12DxN7rBCIN8vuYqafFMF04ks9QV9TFRJOgwbf.8SPmVSpxg M.ECpbY88cJdmD2PFp13oQWL1b5mabCBvtMWmyS8bPLStTtqcIDSJNRJHK8U0DCs9GFA.5KpjQfG PCoZucENTIvB9hXD.5JP1vuScNYydoD.PxJp38nbtJjLfWiTlpYiYlQl54dDAGkcafG8xv1esVO3 c5o2tEy7XOWl5muqamKYR3dpTf_3XeTJNgumB8nGIOpDnVkFb6digzxGCbFSjSBvEfsbEU4oZaNI Ol3ZbI7nCtu_fDGRwUMpNku4XNU_eTRhtgMVFrEoshU_fHQzpmSVBZWvAs6OkHdDfjvvtbpFF7.v MoVDl6CbPbNa9ECg4Xi8dmRt0vaYnYiX7lyIez72fNVHbx_HiE83o922FV48QDSc4e8sPIs_D4tB j4rT81_3n6bicbMYJsL_lrLDmQ8R3RmihovYoVH0G_6aGH95yhixd2_QhXC9aWqS2f2o9qeDghth WAfjjVkv2RWJqBSuXyEQGCdiPuZ61UG6lZi55_rjuz.MbGYBHiCfNSMxw Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 20 Jan 2021 01:42:24 +0000 Received: by smtp405.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6ab45ba876346170a3cb4d9f66d6453d; Wed, 20 Jan 2021 01:42:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: Date: Tue, 19 Jan 2021 17:42:22 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> References: <20210116043740.GA19523@www.zefox.net> <20210116155538.GA24259@www.zefox.net> <20210116220334.GA26756@www.zefox.net> <20210117174006.GA30728@www.zefox.net> <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DL7Yt2dh6z3H30 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.43 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.93)[-0.932]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.31:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.31:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2021 01:42:28 -0000 On 2021-Jan-18, at 21:12, Mark Millard wrote: > On 2021-Jan-18, at 19:19, Mark Millard wrote: >=20 >> . . . >>> FYI: I re-established my access to a RPi2B V1.1 and made >>> it report: "maximum recommended amount (468832 pages)" >>>=20 >>> (The figure can vary some from release to release.) >>>=20 >>> 468832*4096 =3D=3D 1920335872 or a little over 1831 MiBytes >>>=20 >>> For the 4096 Byte pages, that means that the following from >>> gpart fits without complaint (size is in blocks, not pages): >>>=20 >>> 413140992 3686400 da0p2 freebsd-swap (1.8G) >>>=20 >>> 3686400*512 is a little over 1.75 GiByte or 1800 MiByte. So >>> I've left some room below 1831 MiBytes, but not a lot. >>>=20 >>> FYI about my build experiment that is running: >>>=20 >>> # sysctl hw.physmem >>> hw.physmem: 979042304 >>>=20 >>> which, in recent times for armv7, I can (and did) set in >>> /boot/loader.conf on a faster cortex-A7 SBC (that can boot >>> the same media but has more RAM). >>>=20 >>> So I tried a -j4 build, but with LDFLAGS.lld+=3D -Wl,--threads=3D1 >>> in use and my other particular src.conf/make.conf like content >>> (so the builds do likely differ from yours in various ways). >>> My build is producing a non-debug build (but with -g symbols). >>> Somewhat after where your buildworld.log stops, my odd variant >>> of top was reporting: >>>=20 >>> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki = MaxObs(Act+Wir) >>> Swap: . . . , 145832Ki MaxObsUsed >>>=20 >>> and top was also showing lots of processes as having "0B" RES >>> in STATE "wait" or "nanslp" (so, apparently swapped out, not = paging). >>> ("MaxObs" is short for "maximum observed".) >>>=20 >>> For comparison, your swapscript.log reported a maximum total of >>> 346192 KiBytes "Used" for swap, about 98% into the log file. >>>=20 >>> (Time goes by . . .) >>>=20 >>> It finished with building libllvm and is part way into building >>> libclang. This is probably well past where your hangup happened, >>> given that your published buildworldlog file stopped with >>> libllvm's Target/ARM/ARMMCInstLower.o . My odd top now shows: >>>=20 >>> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki = MaxObs(Act+Wir) >>> Swap: . . . , 392328Ki MaxObsUsed >>>=20 >>> The build continues to run. I'll let you know how it goes. >>> . . . >>=20 >> Just after libclang finished my odd top showed: >>=20 >> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892736Ki = MaxObs(Act+Wir) >> Swap: . . . , 537588Ki MaxObsUsed >>=20 >> After liblldb: >>=20 >> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 899276Ki = MaxObs(Act+Wir) >> Swap: . . . , 537588Ki MaxObsUsed >>=20 >> Much later, after the lldb program had been built: >>=20 >> Mem: . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki = MaxObs(Act+Wir) >> Swap: . . . , 537588Ki MaxObsUsed >>=20 >>>>> World build completed on Mon Jan 18 19:10:08 PST 2021 >>>>> World built in 72960 seconds, ncpu: 4, make -j4 >>=20 >> This was building from scratch what was already installed: >>=20 >> # ~/fbsd-based-on-what-freebsd-main.sh=20 >> merge-base: 818390ce0ca539300dd15d7a817784f1e3f7a9b8 >> merge-base: CommitDate: 2021-01-13 21:27:44 +0000 >> 4180404713ec (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. >> 818390ce0ca5 (freebsd/main, freebsd/HEAD, pure-src, main) arm64: fix = early devmap assertion >> FreeBSD OPiP2E_RPi2v11 13.0-CURRENT FreeBSD 13.0-CURRENT = mm-src-c255938-g4180404713ec GENERIC-NODBG arm armv7 1300135 1300135 >>=20 >> This suggests that you should be able to build on the RPi2B v1.1, >> using -j4, with appropriate configuration for what and how to build. >>=20 >>=20 >> It is now building the matching kernel, my GENERIC-NODBG style. >=20 > Done: >=20 >>>> Kernel build for GENERIC-NODBG completed on Mon Jan 18 20:33:26 PST = 2021 >>>> Kernel(s) GENERIC-NODBG built in 4998 seconds, ncpu: 4, make -j4 >=20 > So, World+Kernel in somewhat under 22 hours. >=20 > The "MaxObs*" figures were unchanged, so: >=20 > Mem: . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki = MaxObs(Act+Wir) > Swap: . . . , 537588Ki MaxObsUsed >=20 > This suggests that, for now, 800 MiByte of swap would be something > more than 1.5 times what it actually used and 1050 MiBytes would > be something like 2.0 times what it actually used, so leaving some > notable margin for variations in peek usage, at least when linker > threading is avoided. >=20 >=20 >=20 > As for what I used to control "what and how to build" . . . >=20 > # more = ~/sys_build_scripts.armv7-host/make_armv7_nodebug_clang_bootstrap-armv7-ho= st.sh=20 > kldload -n filemon && \ > script = ~/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-armv7-host= -$(date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.armv7-clang-bootstrap.armv7-hos= t" \ > WITH_META_MODE=3Dyes \ > WORLD_FLAGS=3D"${WORLD_FLAGS} UBLDR_LOADADDR=3D0x42000000" \ > MAKEOBJDIRPREFIX=3D"/usr/obj/armv7_clang/arm.armv7" \ > make $* >=20 > (In my context, UBLDR_LOADADDR is ignored by anything that > can not use the figure given. So I've no bothered to be > more selective about having it in the armv7 builds.) >=20 > # more ~/src.configs/make.conf > LDFLAGS.lld+=3D -Wl,--threads=3D1 >=20 > # more ~/src.configs/src.conf.armv7-clang-bootstrap.armv7-host > TO_TYPE=3Darmv7 > # > KERNCONF=3DGENERIC-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > #WITH_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > WITH_SYSTEM_LINKER=3D > # > WITH_LIBCPLUSPLUS=3D > WITHOUT_BINUTILS_BOOTSTRAP=3D > WITH_ELFTOOLCHAIN_BOOTSTRAP=3D > #Disables avoiding bootstrap: WITHOUT_LLVM_TARGET_ALL=3D > WITHOUT_LLVM_TARGET_AARCH64=3D > WITH_LLVM_TARGET_ARM=3D > WITHOUT_LLVM_TARGET_MIPS=3D > WITHOUT_LLVM_TARGET_POWERPC=3D > WITHOUT_LLVM_TARGET_RISCV=3D > WITHOUT_LLVM_TARGET_X86=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLD=3D > WITH_LLD_IS_LD=3D > WITHOUT_BINUTILS=3D > # > WITH_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > # > WITHOUT_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > WITH_MALLOC_PRODUCTION=3D > WITHOUT_ASSERT_DEBUG=3D > WITHOUT_LLVM_ASSERTIONS=3D > # > # Avoid stripping but do not control host -g status as well: > DEBUG_FLAGS+=3D > # > WITH_REPRODUCIBLE_BUILD=3D > WITH_DEBUG_FILES=3D > # > # Use of the .clang 's here avoids > # interfering with other CFLAGS > # usage, such as ?=3D usage. > CFLAGS.clang+=3D -mcpu=3Dcortex-a7 > CXXFLAGS.clang+=3D -mcpu=3Dcortex-a7 > CPPFLAGS.clang+=3D -mcpu=3Dcortex-a7 >=20 > (I do not claim that you would want WITH_REPRODUCIBLE_BUILD . > I just happen to have been experimenting with it. You might > not want to be explicit about the cpu to target. You might > not want WITH_CLANG_EXTRAS .) >=20 > # more /usr/fbsd/mm-src/sys/arm/conf/GENERIC-NODBG > include "GENERIC" >=20 > ident GENERIC-NODBG >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > options AUDIT # Not enabled by default in = armv7/v6 kernels > # Enabled here to allow kyua = test runs to > # possibly report auditing = works. >=20 > options ALT_BREAK_TO_DEBUGGER >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger >=20 > # Extra stuff: > #options VERBOSE_SYSINIT=3D0 # Enable verbose sysinit = messages > #options BOOTVERBOSE=3D1 > #options BOOTHOWTO=3DRB_VERBOSE > options ALT_BREAK_TO_DEBUGGER # Enter debugger on keyboard = escape sequence > options KLD_DEBUG > #options KTR > #options KTR_MASK=3DKTR_TRAP > ##options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # Disable any extra checking for. . . > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DEADLKRES # Enable the deadlock resolver > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones > nooptions DIAGNOSTIC > nooptions BUF_TRACKING > nooptions FULL_BUF_TRACKING > nooptions USB_DEBUG > nooptions USB_REQ_DEBUG > nooptions USB_VERBOSE >=20 > The /boot/loader.conf file and the /etc/sysctl.conf files > both contained: >=20 > vm.pageout_oom_seq=3D120 > vm.pfault_oom_attempts=3D-1 >=20 > (The hw.physmem=3D979042304 in /boot/loader.conf was very-special, > to better approximate your environment. I also controlled the > cpu frequency used via a line in /etc/sysctl.conf . I do not > bother with such non-default frequency usage [or related settings] > for RPi*'s with the pre-RPi4B style power connections but do > control the frequency for the OPi+2E.) The following had been left implicit about my context and how it manages memory space use. I'll note that I do not use tmpfs or other such memory based file system techniques that could compete for RAM/swap. What is in use for the only file system involved is just the root file system: # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/gpt/BPIM3root 195378 63940 115808 36% / devfs 0 0 0 100% /dev It is a USB SSD. The swap partition is also on that same media. (The BPIM3 based name dates back to before the BPI-M3 power connection failed and I switched to the OPi+2E.) I'll note that I've started a new from-scratch build without LDFLAGS.lld+=3D -Wl,--threads=3D1 . So at some point I'll have information about how much of a difference (+/-) in swap usage it actually made for with vs. without, if any. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jan 20 17:51:42 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 702474FD3FA for ; Wed, 20 Jan 2021 17:51:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DLY4F31kHz3MvJ for ; Wed, 20 Jan 2021 17:51:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611165099; bh=VdWB9QPZLbVOyibkq4OBU5ZqvO3h4LnxoqxvTIA3FvM=; h=Subject:From:Date:To:From:Subject:Reply-To; b=GvvdSeDEUF4npWF1pfDve63abiaXD93NNAJaX3MG3d5UnYgwyYqj/TJ5liu6gsQS4l4pwM/RabB99nq1Yn6R4JsWNAOsaT8aC7nRWJ2m0SD0bpUBmVRPMrX+ED89zxCkzfHDnlh9qVttPQyoKeR6C8F80Fd/OLvUUAnsozxXEO5BIfSWzRE8gFx93S6dvaSGBHrwd0gNftPJtGQwGQgbgKsU7+EViTUdt4Ptvmh3jQeSr4ybO0HaQSBak46fwBNiRD8Ick3BcM2vLpA5GljYg5vDUy9yAYPm/ew83EaSt/9ViWdxUITzWo6TXy8p0JJoOGARyqiY0xKrRmMiBLEUZw== X-YMail-OSG: _si0DgIVM1k8S3TQnyoeSbPnD4M9f5VLxK3zDUDzsX4N8IHZerps.NZptD4nTOp OPvExTaX19gVSlZyABusKQmzKKP2cJ60DqIA4nLwgPITqBVVlynXEG__YXH9tK_qqyttu5w6aqHv r59_CVHM9wAYQeobIwWcn1vS.uNgz7UytR72KqPM.G3st2tuTbh.X3hSx.6Km24IwXl3YAw4IXKL 4YiG_HDWcgoPZxyHTJqhy5zYJ6XC35GC_PDnRks_Iy4EcE9.r6moxL.TZyuI3CtaWFooXaip4yMk QzI70TQyfylQ9Lns8LSOzo8wvH4OPbkNSrjDqKKeLgzXqJcnFlMTVUiBEDiQEla2c.enOYIpFN_f mM6boNuxBN00S1ZPHGWN3JjmTjH_ZuB.uftVZx2I7QiF1yLC6Xf8FeKUnRLdb78.1xORdy_heAE4 qGBhtu24hey9HW58xp4kf7t3puzA91VxVua8KE56FmzyZ1aVX9UhhP24eB5kt.7QUuEmha7qRnNU Fiuq0mtQPpH6GC9dCoaVqDJo0Do647nJ_PQCBHgI4Q1.qnW4_98xMz.O4mUWzDavGAuXcqAvkJ.H TgT07DTwwexoUQHwEsVZHiOUbrNyQt7x3ua00DBzyek5LDFQAF7UlNfAloV8N_bFI4KGsnlhXvPp zOUvK2yAL.XvtGGp.F2dmz5yQfvJKu3lZAelpQ9Oq4TZYqolPO.2euhJeZzsFo2epU5j58DfyXKP 3T8eExag6AVEF6rkyc0yfIRhcPIjIqO8FEaTOyY1ssbVXjDsBSEqEXCqWk.fAE39pZzHTqNz2CRR kmMpf1Nx65kZkVI0PrC5T_lPgiqhfaG7DRx3OfTdNUneUXwFhHCkaag2kcTFgwif9aMaH.ej9fEP xGfik91JsrT_CmLzxzpEyX66cMDvmKBJxhV95KgeZd3UMOb9llKuA2rjPfVciKA7yCTcAnVu0DR9 vnMzSg3oRBRuWQ00rr16SXhjt9qBQeyZQ92lKHmdUQQ6Sd3IXytVPyNSRuwRBdbzyVOysy35auga QUtrnBtktiAptk9j9lYiNK1jY7lBFgBJ3Kc3vmx5UQ984n2AKOSMnflLRHhX__b0kasjIEYC8ZZZ B1tPSXId_RS4PGfRP1H5tp4pDExMtWuGXAXSV9ANaBytmH59fLjZDn9mGdLrt5BaIVFbn0g463ZL DPJpScT3Nz.6bSHrMF2Voi.lvFIV_m_FGy90dQD.nNrWKc0Fx.WPH9guEkobvzN6G2GL6YvNHA9L 6CPvtAPJCkFLMVfukDkOZGiGQf7OTrlHJVWLwOqCFzix_uxIcChlZKtrJl4Vp7GQoNGFJvX72al5 x2W8xT.7okdh.h919BH1iXn5lYY8tXA_rhfYMzx9d9xxie.5nSBYhXhFduQs9zkEqoDS63ZwXH8L kWiUp7j9O37AqVBx.WZg9WFu6f57nPZrrGgng_GDX48PL0wHvjKLSEAJL9D9GxBzWSukQORY222R MSp0qJZ6KL7QRWkrHrhenbYnemA3OyetTH6WrgNvHf6.RH3PMgyv399K7PkrD6hT4CmO0miwF98Q As_OB56E5mC6ZLoMYcGB8ZXkY.Xbpxx5mAkeeOGWW6lqzHHIKmIwAac73k88vWnYAzi7aj9wOGVm u_zkI38oxnbrgOeGexKX0rCXLyq9_yPrqNpdCw20B2Qm49kVETtIMceDlAKZZkHWhBw0wpokwpVQ I23xdvNEPu050Gv4Jskw6rie2ALTUOOtNlcTDlqfk_DEIcjcyaOCRhkQe85X6.MN.elfgeKQjDC0 4jmizYxwmZfTr4j0zZm6uF96_2B.MFQSZHv2qa.HD8J92Ki67myGIZB199MMZ1BhDpI4C25WgKxA KSE81XoWQtej_nZS.YMAB3BcO9SVu8tLA6ZkoBvNiCJPjECgYs0Hvg4MSEm8fH_ck3ukIuuCD_g9 oLTazAiv2Y0CnCht58sVwR.kW2klfsuxZCJMUk4dFK72EwTWiBbhb3sfn4NjYfgGaobUSTwwVyj1 k.h6Gcfd7SI8bHa.yCpSuehMJEo3Yj6FJ1RAUooTKxBO5DC4L12rK8UYqUupKt1I4HKLUJF9FU0P mxgFpK2p3O4dVXMatRcUqjC.1ZrTX9KCowhM5IOFGZhJj8kllo.CfHj8XvAIQuRHj7YJShSOISOQ RJjh9h8tiVklLdrdWQBzMewZpppk8P4X_4d7kTpR2QpkqFQ9Gfx3a3XbJEvZShoDNA7n0i.iqJEa 4ZgRp6h9e864RLS9U1dOjcPheQoRXuWDDdsRN3O3PO6_fmE0nuSpy.xS2t26VLIhW8u8B0yfh91J nnFqINQJ_Oab1Wv923wNgTUkaHDNIFiVXzUfhmNkrRgrzB.Nd60nCyyK8loUGRw5YMvC83TfsIH3 L3LfWyXDDB__b6yWQZZu8UA9GvZXmn4EqqCEL.FanWngSxL8rBwGFw6Ig1kn9i1vLVqae0qwkS9n T5AIOxuShUOADcm_bfQOdCSSe5sWDc6i9ibe0_PjmHtmwNl5vSKZxbld5X4JCKkRbIDC.cNaFWh5 qW4e00N8q7pZaGRoEAT0iHYisNAUVHUVk4NpcSUJp.KwilhY81w0U2A4CPAECRkN7SGcqDi973kw aaz_.3M.WMV9AZ0zet5hYhg0oobu_6h4mfqOT5Y70ORaA1s2TOUSa360l Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 20 Jan 2021 17:51:39 +0000 Received: by smtp402.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7410524d06d0214790ba9d4f554a1e90; Wed, 20 Jan 2021 17:51:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> Date: Wed, 20 Jan 2021 09:51:33 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210116043740.GA19523@www.zefox.net> <20210116155538.GA24259@www.zefox.net> <20210116220334.GA26756@www.zefox.net> <20210117174006.GA30728@www.zefox.net> <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DLY4F31kHz3MvJ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.31 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.81)[-0.807]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.205:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.205:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.205:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2021 17:51:42 -0000 On 2021-Jan-19, at 17:42, Mark Millard wrote: > On 2021-Jan-18, at 21:12, Mark Millard wrote: >=20 >> On 2021-Jan-18, at 19:19, Mark Millard wrote: >>=20 >>> . . . >>>> FYI: I re-established my access to a RPi2B V1.1 and made >>>> it report: "maximum recommended amount (468832 pages)" >>>>=20 >>>> (The figure can vary some from release to release.) >>>>=20 >>>> 468832*4096 =3D=3D 1920335872 or a little over 1831 MiBytes >>>>=20 >>>> For the 4096 Byte pages, that means that the following from >>>> gpart fits without complaint (size is in blocks, not pages): >>>>=20 >>>> 413140992 3686400 da0p2 freebsd-swap (1.8G) >>>>=20 >>>> 3686400*512 is a little over 1.75 GiByte or 1800 MiByte. So >>>> I've left some room below 1831 MiBytes, but not a lot. >>>>=20 >>>> FYI about my build experiment that is running: >>>>=20 >>>> # sysctl hw.physmem >>>> hw.physmem: 979042304 >>>>=20 >>>> which, in recent times for armv7, I can (and did) set in >>>> /boot/loader.conf on a faster cortex-A7 SBC (that can boot >>>> the same media but has more RAM). >>>>=20 >>>> So I tried a -j4 build, but with LDFLAGS.lld+=3D -Wl,--threads=3D1 >>>> in use and my other particular src.conf/make.conf like content >>>> (so the builds do likely differ from yours in various ways). >>>> My build is producing a non-debug build (but with -g symbols). >>>> Somewhat after where your buildworld.log stops, my odd variant >>>> of top was reporting: >>>>=20 >>>> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki = MaxObs(Act+Wir) >>>> Swap: . . . , 145832Ki MaxObsUsed >>>>=20 >>>> and top was also showing lots of processes as having "0B" RES >>>> in STATE "wait" or "nanslp" (so, apparently swapped out, not = paging). >>>> ("MaxObs" is short for "maximum observed".) >>>>=20 >>>> For comparison, your swapscript.log reported a maximum total of >>>> 346192 KiBytes "Used" for swap, about 98% into the log file. >>>>=20 >>>> (Time goes by . . .) >>>>=20 >>>> It finished with building libllvm and is part way into building >>>> libclang. This is probably well past where your hangup happened, >>>> given that your published buildworldlog file stopped with >>>> libllvm's Target/ARM/ARMMCInstLower.o . My odd top now shows: >>>>=20 >>>> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki = MaxObs(Act+Wir) >>>> Swap: . . . , 392328Ki MaxObsUsed >>>>=20 >>>> The build continues to run. I'll let you know how it goes. >>>> . . . >>>=20 >>> Just after libclang finished my odd top showed: >>>=20 >>> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892736Ki = MaxObs(Act+Wir) >>> Swap: . . . , 537588Ki MaxObsUsed >>>=20 >>> After liblldb: >>>=20 >>> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 899276Ki = MaxObs(Act+Wir) >>> Swap: . . . , 537588Ki MaxObsUsed >>>=20 >>> Much later, after the lldb program had been built: >>>=20 >>> Mem: . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki = MaxObs(Act+Wir) >>> Swap: . . . , 537588Ki MaxObsUsed >>>=20 >>>>>> World build completed on Mon Jan 18 19:10:08 PST 2021 >>>>>> World built in 72960 seconds, ncpu: 4, make -j4 >>>=20 >>> This was building from scratch what was already installed: >>>=20 >>> # ~/fbsd-based-on-what-freebsd-main.sh=20 >>> merge-base: 818390ce0ca539300dd15d7a817784f1e3f7a9b8 >>> merge-base: CommitDate: 2021-01-13 21:27:44 +0000 >>> 4180404713ec (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. >>> 818390ce0ca5 (freebsd/main, freebsd/HEAD, pure-src, main) arm64: fix = early devmap assertion >>> FreeBSD OPiP2E_RPi2v11 13.0-CURRENT FreeBSD 13.0-CURRENT = mm-src-c255938-g4180404713ec GENERIC-NODBG arm armv7 1300135 1300135 >>>=20 >>> This suggests that you should be able to build on the RPi2B v1.1, >>> using -j4, with appropriate configuration for what and how to build. >>>=20 >>>=20 >>> It is now building the matching kernel, my GENERIC-NODBG style. >>=20 >> Done: >>=20 >>>>> Kernel build for GENERIC-NODBG completed on Mon Jan 18 20:33:26 = PST 2021 >>>>> Kernel(s) GENERIC-NODBG built in 4998 seconds, ncpu: 4, make -j4 >>=20 >> So, World+Kernel in somewhat under 22 hours. >>=20 >> The "MaxObs*" figures were unchanged, so: >>=20 >> Mem: . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki = MaxObs(Act+Wir) >> Swap: . . . , 537588Ki MaxObsUsed >>=20 >> This suggests that, for now, 800 MiByte of swap would be something >> more than 1.5 times what it actually used and 1050 MiBytes would >> be something like 2.0 times what it actually used, so leaving some >> notable margin for variations in peek usage, at least when linker >> threading is avoided. >>=20 >>=20 >>=20 >> As for what I used to control "what and how to build" . . . >>=20 >> # more = ~/sys_build_scripts.armv7-host/make_armv7_nodebug_clang_bootstrap-armv7-ho= st.sh=20 >> kldload -n filemon && \ >> script = ~/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-armv7-host= -$(date +%Y-%m-%d:%H:%M:%S) \ >> env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.armv7-clang-bootstrap.armv7-hos= t" \ >> WITH_META_MODE=3Dyes \ >> WORLD_FLAGS=3D"${WORLD_FLAGS} UBLDR_LOADADDR=3D0x42000000" \ >> MAKEOBJDIRPREFIX=3D"/usr/obj/armv7_clang/arm.armv7" \ >> make $* >>=20 >> (In my context, UBLDR_LOADADDR is ignored by anything that >> can not use the figure given. So I've no bothered to be >> more selective about having it in the armv7 builds.) >>=20 >> # more ~/src.configs/make.conf >> LDFLAGS.lld+=3D -Wl,--threads=3D1 >>=20 >> # more ~/src.configs/src.conf.armv7-clang-bootstrap.armv7-host >> TO_TYPE=3Darmv7 >> # >> KERNCONF=3DGENERIC-NODBG >> TARGET=3Darm >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> #WITH_CROSS_COMPILER=3D >> WITH_SYSTEM_COMPILER=3D >> WITH_SYSTEM_LINKER=3D >> # >> WITH_LIBCPLUSPLUS=3D >> WITHOUT_BINUTILS_BOOTSTRAP=3D >> WITH_ELFTOOLCHAIN_BOOTSTRAP=3D >> #Disables avoiding bootstrap: WITHOUT_LLVM_TARGET_ALL=3D >> WITHOUT_LLVM_TARGET_AARCH64=3D >> WITH_LLVM_TARGET_ARM=3D >> WITHOUT_LLVM_TARGET_MIPS=3D >> WITHOUT_LLVM_TARGET_POWERPC=3D >> WITHOUT_LLVM_TARGET_RISCV=3D >> WITHOUT_LLVM_TARGET_X86=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_CLANG_EXTRAS=3D >> WITH_LLD=3D >> WITH_LLD_IS_LD=3D >> WITHOUT_BINUTILS=3D >> # >> WITH_LLDB=3D >> # >> WITH_BOOT=3D >> WITHOUT_LIB32=3D >> # >> # >> WITHOUT_WERROR=3D >> #WERROR=3D >> MALLOC_PRODUCTION=3D >> WITH_MALLOC_PRODUCTION=3D >> WITHOUT_ASSERT_DEBUG=3D >> WITHOUT_LLVM_ASSERTIONS=3D >> # >> # Avoid stripping but do not control host -g status as well: >> DEBUG_FLAGS+=3D >> # >> WITH_REPRODUCIBLE_BUILD=3D >> WITH_DEBUG_FILES=3D >> # >> # Use of the .clang 's here avoids >> # interfering with other CFLAGS >> # usage, such as ?=3D usage. >> CFLAGS.clang+=3D -mcpu=3Dcortex-a7 >> CXXFLAGS.clang+=3D -mcpu=3Dcortex-a7 >> CPPFLAGS.clang+=3D -mcpu=3Dcortex-a7 >>=20 >> (I do not claim that you would want WITH_REPRODUCIBLE_BUILD . >> I just happen to have been experimenting with it. You might >> not want to be explicit about the cpu to target. You might >> not want WITH_CLANG_EXTRAS .) >>=20 >> # more /usr/fbsd/mm-src/sys/arm/conf/GENERIC-NODBG >> include "GENERIC" >>=20 >> ident GENERIC-NODBG >>=20 >> makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >>=20 >> options AUDIT # Not enabled by default in = armv7/v6 kernels >> # Enabled here to allow kyua = test runs to >> # possibly report auditing = works. >>=20 >> options ALT_BREAK_TO_DEBUGGER >>=20 >> options KDB # Enable kernel debugger = support >>=20 >> # For minimum debugger support (stable branch) use: >> options KDB_TRACE # Print a stack trace for a = panic >> options DDB # Enable the kernel debugger >>=20 >> # Extra stuff: >> #options VERBOSE_SYSINIT=3D0 # Enable verbose sysinit = messages >> #options BOOTVERBOSE=3D1 >> #options BOOTHOWTO=3DRB_VERBOSE >> options ALT_BREAK_TO_DEBUGGER # Enter debugger on keyboard = escape sequence >> options KLD_DEBUG >> #options KTR >> #options KTR_MASK=3DKTR_TRAP >> ##options KTR_CPUMASK=3D0xF >> #options KTR_VERBOSE >>=20 >> # Disable any extra checking for. . . >> nooptions INVARIANTS # Enable calls of extra = sanity checking >> nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS >> nooptions WITNESS # Enable checks to detect = deadlocks and cycles >> nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed >> nooptions DEADLKRES # Enable the deadlock = resolver >> nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones >> nooptions DIAGNOSTIC >> nooptions BUF_TRACKING >> nooptions FULL_BUF_TRACKING >> nooptions USB_DEBUG >> nooptions USB_REQ_DEBUG >> nooptions USB_VERBOSE >>=20 >> The /boot/loader.conf file and the /etc/sysctl.conf files >> both contained: >>=20 >> vm.pageout_oom_seq=3D120 >> vm.pfault_oom_attempts=3D-1 >>=20 >> (The hw.physmem=3D979042304 in /boot/loader.conf was very-special, >> to better approximate your environment. I also controlled the >> cpu frequency used via a line in /etc/sysctl.conf . I do not >> bother with such non-default frequency usage [or related settings] >> for RPi*'s with the pre-RPi4B style power connections but do >> control the frequency for the OPi+2E.) >=20 > The following had been left implicit about my context and > how it manages memory space use. >=20 > I'll note that I do not use tmpfs or other such memory based > file system techniques that could compete for RAM/swap. What > is in use for the only file system involved is just the > root file system: >=20 > # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/gpt/BPIM3root 195378 63940 115808 36% / > devfs 0 0 0 100% /dev >=20 > It is a USB SSD. The swap partition is also on that same > media. (The BPIM3 based name dates back to before the > BPI-M3 power connection failed and I switched to the > OPi+2E.) >=20 > I'll note that I've started a new from-scratch build without > LDFLAGS.lld+=3D -Wl,--threads=3D1 . So at some point I'll have > information about how much of a difference (+/-) in swap > usage it actually made for with vs. without, if any. Looks like, for such 4-core contexts, that bothering with LDFLAGS.lld+=3D -Wl,--threads=3D1 is typically a waste of effort for both swap usage and time . . . With LDFLAGS.lld+=3D -Wl,--threads=3D1 : Mem: . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki = MaxObs(Act+Wir) Swap: . . . , 537588Ki MaxObsUsed without: Mem: . . ., 715756Ki MaxObsActive, 194816Ki MaxObsWired, 903132Ki = MaxObs(Act+Wir) Swap: . . ., 557208Ki MaxObsUsed With LDFLAGS.lld+=3D -Wl,--threads=3D1 : World built in 72960 seconds, ncpu: 4, make -j4 Kernel(s) GENERIC-NODBG built in 4998 seconds, ncpu: 4, make -j4 without: World built in 72804 seconds, ncpu: 4, make -j4 Kernel(s) GENERIC-NODBG built in 4824 seconds, ncpu: 4, make -j4 So, just not that much of a difference compared to the overall sizes or times involved. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jan 20 22:26:09 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B527A4DBC6C for ; Wed, 20 Jan 2021 22:26:09 +0000 (UTC) (envelope-from olevole@olevole.ru) 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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DLg8w1GLsz3vxg for ; Wed, 20 Jan 2021 22:26:07 +0000 (UTC) (envelope-from olevole@olevole.ru) Received: by mail-ej1-x62f.google.com with SMTP id l9so30038606ejx.3 for ; Wed, 20 Jan 2021 14:26:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=34yzc3b4d4Y9EJsnyXiwXmhXc+aiPQjxU0Gk112WwPA=; b=M57X01Lq6HXpwTiMQM6XBkyS7cmATyPLsHOy7Zc4mVTnJHLl4PjbFAZ+YdyvQZX8MJ Tos66WqxrfvgNblm2xJ+4YapVUDeYbpuxFoGO2SoYrFl1Fg6O5fIUk+jlf3XI7zz/kcy oO7Wx74soN7Sq9LNYcsSbRayF45dYzZ+psGnwNPGubjRYtiJH4c9FH4pQn66KZshD+ZE bGzxabefaF8V1zb94qx0Hr4t3nWh6vouKMkS1gghBlSUNrdRkReUYAyVr7vwAl1rpS/D oWTHaGVGVasYmC8gt3yP8k6NyllZX4NLvlphOmiVw7MZVOfwxKZ2W4rpTXlYgeP+vLDT zOgg== X-Gm-Message-State: AOAM530H7fV+KjFrpcUO/Tae4VOJD0QJk0xy8C7hhF19LrL+zq0QdG3C 654+whZWrsh7ex0toaVFflwam3j1KmgWX/oREn/DDfD04xenbF1I X-Google-Smtp-Source: ABdhPJzcPoPwZ09PLuAdE2ItebrZjgN8yimucnWhZ69K4rlZUlGi8dDXoE77ERux+H8/mWzCmZxbzRedm8Fx2as+m7I= X-Received: by 2002:a17:906:7d09:: with SMTP id u9mr6971609ejo.380.1611181566155; Wed, 20 Jan 2021 14:26:06 -0800 (PST) MIME-Version: 1.0 From: Oleg Ginzburg Date: Thu, 21 Jan 2021 01:25:54 +0300 Message-ID: Subject: FreeBSD on RPI4B: shows an incorrect value of RAM To: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 4DLg8w1GLsz3vxg X-Spamd-Bar: - X-Spamd-Result: default: False [-1.17 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[olevole-ru.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.993]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::62f:from:127.0.2.255]; DMARC_NA(0.00)[olevole.ru]; DKIM_TRACE(0.00)[olevole-ru.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.86)[-0.864]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::62f:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2021 22:26:09 -0000 Hello maillist, Recently became the owner of an RPI4-B board. Latest FreeBSD snapshot ( FreeBSD-13.0-CURRENT-arm64-aarch64-RPI-20210107-f2b794e1e90-255641.img ) boots successfully. However, for some reason, the system only sees 3.1 gigabytes. This model has 8 GB of RAM. Any ideas? https://www.bsdstore.ru/trash/IMG_20210121_000558.jpg https://www.bsdstore.ru/trash/IMG_20210120_224751.jpg ps: booted from SD via RPI_EFI.fd ( https://github.com/pftf/RPi4/releases/tag/v1.22 ), config.txt: disable_splash=1 arm_64bit=1 enable_uart=1 uart_2ndstage=1 enable_gic=1 armstub=RPI_EFI.fd #disable_commandline_tags=1 #disable_overscan=1 #device_tree_address=0x1f0000 #device_tree_end=0x200000 #dtoverlay=miniuart-bt From owner-freebsd-arm@freebsd.org Wed Jan 20 23:06:32 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F3E314DC918 for ; Wed, 20 Jan 2021 23:06:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DLh3V4bTYz4S0T for ; Wed, 20 Jan 2021 23:06:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611183988; bh=uxLeqwrLjkD8saF2CPctsJaBkKwAjI2wzhgOeFFGB61=; h=Subject:From:Date:To:From:Subject:Reply-To; b=BYezW7VLfQE8Y7+a1BAqieBZ0yc6MEDQWvjp6BZJBLI2kGGBI3F2GW7mLDFpTt9shrB/1HTWFWyB3g0FewYVN04uMlMdzNP5GbpTWHZD9i4fI0CcqiRuxa53IgYIlrwIWBUK/NuSN8jJx/8NXzyUpX1Nmug/ZdqUBNmOSFckOnKgnR4N4c3Rh+t9BWURWtAj4WWh9bO8n/1keanala7UA6OwaYStY20iAAIlncoWyrBzwtH/WKrRnP7Q84noSTJaOiPNwtPSsRmCJdSHUHsxe9Ib9yR6+rt/RLGkAURPGwJMG1/gEp6ztGVd/NoFh9rpj++s7xZy3QoV3lBTlemj5Q== X-YMail-OSG: V8ZWrLEVM1nK1ciCISvo5.BpV47XoAN72jr.6M3OMMFYyZK2gsciOoRrfpNq_6B X9.fYUIF0W2u0eS_wo2CjZ_87JJmx4vPi73nDaLnNT0XMXfeEfVsHyD2GpybBXQHWKs_0G9p2wcx MXpPtbH_SJra4Zyys8EqeMiD45Q3lc2w7MnbGaQzbxaAeIygsLQFJLpX84fKal1iwD9g3l8V_TQa Cmi7oIkgvmHse31mAP.aSjxleIALhLgxwD9t9kNFjmjYD3qDdHF_W29thRrji6Uu0yifqJzHUgAc 6jMPSivRo2eQttoyGJwjs18g1H6.rGnhKKhPIlsXeplx7dCRgMmSozzhM372ZS.BLhj_xc3x0VDv q4De1UJxWbpLgzHQ49zYgf8edvn_dz8FD52IRJposMw9sK1IO63DCvPHjBA7mjdhHD_PPGDOXqp. q4MDKtXMwGi0ANAbXWrnFqoULwBLdHxbb1hAXIvUAfbZx93tR99JpqulaZytAZWN3DxWpK553xV6 fapPnjmtk5kZvX6WWnCCyWtA.KHsKZEOHu0bv3.XhA4b7Z4DzBrzvLFu0zVp.3qCv7M9E8ChbBEX l3TlGnl8cc.l.SirRKFa1S3wudVyGzrZ1qOAQSuKH_Q7eTJaej342GP5I47_6IvBiUMr3b8NU.x8 l5C7XI.NXKq8E24f9zHsLVf8.ZWzAdapm171gIXIo8mt.OMXYY6E9p.LaaVGnKO3ac4miwqCJL0r 2mUkQGRByIMuFQO1VtUgKfAH9yN6yaOFiy1IQueX7XLwLGRm0z70hqJyk.WAXwWzDsVIA1zUPSXH _Oq0PxlxbrxjzFmGUnhYvksTLRkbdKaEvyzq95cZaBzXezKFDE1nPLPDU._XFCveg0oeGs_5w25s MN47kltz21JaZNWobIO2JuJ8PVlYtfj9kLloi_FO75EONlCDlWliduS63rvk9c9s0JblyGNbqTyd YaGpU6PBJpdVHradIDwsvlsdeaYc6d_Uhb8pcgINy7mCFPdCirs2do0aW98SAPcn8aOqAunu3cUn RDb1PsEZK05Vorhf6GNfU13DCLwpyn2iHXuCxK7PDmqhZjkYH1YIobO5paMoK3hC1JXv.e3PbNGg gRCXIJmP0HshfdNOq0Yd8xVUK9ZrXrmOiukAR7B080dnk4rLfDC0vaSZpdxt9.e4OEyF0luXS27V l4tg5frpnlyGeRs3wjYPCLGcIJIXqpuncyEtwNjDzm1hPvpGxAkscT6RXHAxRnAEjBBATR2IvpvC d_8k5XVajsE2khmS853wjSqx2oPHMbZy1uDYrqqrWW9rwaxWu0fVYdJhAqBzSMHQANZDD.4.ePuz AcXINwdj8ZV7LQ.y_axs0S9dWVxPgKqttRZK5w80qYFMMNLyE4godLVoeelRQSJhX9Gj.6K6Dh4N jt2Cy4dS0_3g6f1DC_oiKbm1wBV5MPuZQEXIuJ2AOGuFFt8uQzZnrAX2QyWeUUgtOJ4QBXAo1oj. lE3nLNWyrpPbew6A1tW2MNbEaTvx4jQv1bCPWrziPvH965GwKHAXqHmZffkOGTr5k8jHCtuw9NJ_ y0TtDk.l2QkXp7WLZsvHQUG1aDj5rQzTPjrNdNxbZMq9pK6wQxtlsB72YyQooGUNm2yRqCN3aj.d lS1YEJFrOIKXZ7H0M7jgDykXcK4qnfYo8yhSJcTLrvM87fxwkCLl6OMsIdi_2extyhvGTeUM_E1A 0uP.tv20UWYRlvSRzQEhpy28sH5Mz8WuY9UOwn3bDQHjo_vVwxs._1LwVgiHO2LcocsSMkLxaIgU 9rrSBkzVNt6JUK3POaHqiUcX5U_Jef0jiCfV.N8x7bnmGLcyIuhhcX8vMyjIdmfQhfcyhI6tQjsc 6qgkU5wWgrprbBzlvvgI61.3fUtwLwHuc3mY_nIuDso4S2_RNHi1LX2L96rBS9iNyT7DChqWsrmx .mhy0NYAXdwPBazSlPCqMdGJTmvchCfrDahykZWQ8yRYS80NzqDsE6pdDSntAf9VfbTGk_i7QyJr 9hhGPsMNU9RMXPN2iyut4JLUAweQidNKmEufeGzhJF5fseEgIIHC5nEOJNJ3gTr9E8.iEK5LUTwJ ngZb8VHX.v0sWu24KIR5BDOlSCAVKOIVju_sOoFVpAOvCgl5Q6q8bVflyvSL6NCZd3ZoTljdLra0 cuIKYS7jt4TFb0JOR5pO8dSn5BO77pV2j_mqeYZG4a5BQI2niq3jHd9kHgBX4vZSHzzVq.goR.13 tW3R_bMjftI3slu6NZ619BwS1o4Nwe0A5i7JxTx4QkcZFeTJmUd0euW3ZwCDjVD26tq_ABedk0iw vl9a_7Oa4ZRvsff1qd7MBXxHajxkjiX7UnSIxXuI8VNeBn3C2MkHlEXjHx1WcFzkeSq8a1Xu8DwP 53ZEfKUBfGs2YRJEfzRggbUvOTjLSsJ5Ho7c7JQQ8O82jFwQpwuTgIN4fS1EPx8sZ9WACSxRKPEn HdMDsagyW.vqfbo6ZS97wF0DTNOPRWKdLzeaksQLH7YiEheJZVtOieh.vz1GtsKZyq4Rdl3o486E N0A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Wed, 20 Jan 2021 23:06:28 +0000 Received: by smtp410.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4d875f89bb5e2e551fa1acccdbb16ff0; Wed, 20 Jan 2021 23:06:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: FreeBSD on RPI4B: shows an incorrect value of RAM From: Mark Millard In-Reply-To: Date: Wed, 20 Jan 2021 15:06:21 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Oleg Ginzburg X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DLh3V4bTYz4S0T X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2021 23:06:32 -0000 On 2021-Jan-20, at 14:25, Oleg Ginzburg via freebsd-arm = wrote: > Recently became the owner of an RPI4-B board. Latest FreeBSD snapshot = ( > FreeBSD-13.0-CURRENT-arm64-aarch64-RPI-20210107-f2b794e1e90-255641.img = ) > boots successfully. However, for some reason, the system only sees 3.1 > gigabytes. > This model has 8 GB of RAM. Any ideas? >=20 > https://www.bsdstore.ru/trash/IMG_20210121_000558.jpg > https://www.bsdstore.ru/trash/IMG_20210120_224751.jpg >=20 > ps: booted from SD via RPI_EFI.fd ( > https://github.com/pftf/RPi4/releases/tag/v1.22 ), config.txt: >=20 > disable_splash=3D1 > arm_64bit=3D1 > enable_uart=3D1 > uart_2ndstage=3D1 > enable_gic=3D1 > armstub=3DRPI_EFI.fd > #disable_commandline_tags=3D1 > #disable_overscan=3D1 > #device_tree_address=3D0x1f0000 > #device_tree_end=3D0x200000 > #dtoverlay=3Dminiuart-bt The UEFI/ACPI ( RPI_EFI.fd ) means of booting has the UEFI defaults being to restrict to 3 GiByte of RAM. It can be changed and saved in UEFI. Or you can boot via an appropriate u-boot based boot-configuration that will not restrict itself. However, last I tested an unpatched FreeBSD, FreeBSD does not handle DMA for file system activity correctly when there is more than 3 GiByte of RAM: duplicating a large file like (from my context): -rw-r--r-- 1 root wheel 11570948096 Jul 18 18:32:37 2020 = /usr/obj/clang-armv7-on-aarch64.tar to: -rw-r--r-- 1 root wheel 11570948096 Jul 18 18:32:37 2020 = /usr/obj/clang-armv7-on-aarch64.alt_tar and then using diff or cmp or such on the two files will report there being differences. Small files also could get such behavior (which is how I found the problem originally). Big enough files have always had a copy failure for some part(s) of the file. FYI: The RPi4B's have an error that OS's have to work around in order for DMA to work right. The work-around is not complete/correct yet in any committed update so far as I know. Part of it was DMA_HIGH_LIMIT being too large relative to page boundaries for how the code uses it: one too many pages used as a result. Some other code from experiments that were done also probably also should be reverted (for example, put back some of the BUS_SPACE_MAXSIZE use: maxsize and maxsegsize arguments). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Jan 21 02:34:02 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B65BD4E3ED0; Thu, 21 Jan 2021 02:34:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DLmfx3mtzz4hLm; Thu, 21 Jan 2021 02:34:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 10L2XwVZ059488 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 20 Jan 2021 18:33:58 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 10L2XwRG059485; Wed, 20 Jan 2021 18:33:58 -0800 (PST) (envelope-from fbsd) Date: Wed, 20 Jan 2021 18:33:58 -0800 From: bob prohaska To: Mark Millard Cc: Current FreeBSD , freebsd-arm@freebsd.org Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld Message-ID: <20210121023358.GA58854@www.zefox.net> References: <20210117174006.GA30728@www.zefox.net> <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DLmfx3mtzz4hLm X-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-arm]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 02:34:02 -0000 On Wed, Jan 20, 2021 at 09:51:33AM -0800, Mark Millard wrote: > On 2021-Jan-19, at 17:42, Mark Millard wrote: > > > On 2021-Jan-18, at 21:12, Mark Millard wrote: > > > >> On 2021-Jan-18, at 19:19, Mark Millard wrote: > >> > >>> . . . > >>>> FYI: I re-established my access to a RPi2B V1.1 and made > >>>> it report: "maximum recommended amount (468832 pages)" > >>>> > >>>> (The figure can vary some from release to release.) > >>>> > >>>> 468832*4096 == 1920335872 or a little over 1831 MiBytes > >>>> > >>>> For the 4096 Byte pages, that means that the following from > >>>> gpart fits without complaint (size is in blocks, not pages): > >>>> > >>>> 413140992 3686400 da0p2 freebsd-swap (1.8G) > >>>> > >>>> 3686400*512 is a little over 1.75 GiByte or 1800 MiByte. So > >>>> I've left some room below 1831 MiBytes, but not a lot. > >>>> > >>>> FYI about my build experiment that is running: > >>>> > >>>> # sysctl hw.physmem > >>>> hw.physmem: 979042304 > >>>> > >>>> which, in recent times for armv7, I can (and did) set in > >>>> /boot/loader.conf on a faster cortex-A7 SBC (that can boot > >>>> the same media but has more RAM). > >>>> > >>>> So I tried a -j4 build, but with LDFLAGS.lld+= -Wl,--threads=1 > >>>> in use and my other particular src.conf/make.conf like content > >>>> (so the builds do likely differ from yours in various ways). > >>>> My build is producing a non-debug build (but with -g symbols). > >>>> Somewhat after where your buildworld.log stops, my odd variant > >>>> of top was reporting: > >>>> > >>>> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki MaxObs(Act+Wir) > >>>> Swap: . . . , 145832Ki MaxObsUsed > >>>> > >>>> and top was also showing lots of processes as having "0B" RES > >>>> in STATE "wait" or "nanslp" (so, apparently swapped out, not paging). > >>>> ("MaxObs" is short for "maximum observed".) > >>>> > >>>> For comparison, your swapscript.log reported a maximum total of > >>>> 346192 KiBytes "Used" for swap, about 98% into the log file. > >>>> > >>>> (Time goes by . . .) > >>>> > >>>> It finished with building libllvm and is part way into building > >>>> libclang. This is probably well past where your hangup happened, > >>>> given that your published buildworldlog file stopped with > >>>> libllvm's Target/ARM/ARMMCInstLower.o . My odd top now shows: > >>>> > >>>> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki MaxObs(Act+Wir) > >>>> Swap: . . . , 392328Ki MaxObsUsed > >>>> > >>>> The build continues to run. I'll let you know how it goes. > >>>> . . . > >>> > >>> Just after libclang finished my odd top showed: > >>> > >>> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892736Ki MaxObs(Act+Wir) > >>> Swap: . . . , 537588Ki MaxObsUsed > >>> > >>> After liblldb: > >>> > >>> Mem: . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 899276Ki MaxObs(Act+Wir) > >>> Swap: . . . , 537588Ki MaxObsUsed > >>> > >>> Much later, after the lldb program had been built: > >>> > >>> Mem: . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki MaxObs(Act+Wir) > >>> Swap: . . . , 537588Ki MaxObsUsed > >>> > >>>>>> World build completed on Mon Jan 18 19:10:08 PST 2021 > >>>>>> World built in 72960 seconds, ncpu: 4, make -j4 > >>> > >>> This was building from scratch what was already installed: > >>> > >>> # ~/fbsd-based-on-what-freebsd-main.sh > >>> merge-base: 818390ce0ca539300dd15d7a817784f1e3f7a9b8 > >>> merge-base: CommitDate: 2021-01-13 21:27:44 +0000 > >>> 4180404713ec (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. > >>> 818390ce0ca5 (freebsd/main, freebsd/HEAD, pure-src, main) arm64: fix early devmap assertion > >>> FreeBSD OPiP2E_RPi2v11 13.0-CURRENT FreeBSD 13.0-CURRENT mm-src-c255938-g4180404713ec GENERIC-NODBG arm armv7 1300135 1300135 > >>> > >>> This suggests that you should be able to build on the RPi2B v1.1, > >>> using -j4, with appropriate configuration for what and how to build. > >>> > >>> > >>> It is now building the matching kernel, my GENERIC-NODBG style. > >> > >> Done: > >> > >>>>> Kernel build for GENERIC-NODBG completed on Mon Jan 18 20:33:26 PST 2021 > >>>>> Kernel(s) GENERIC-NODBG built in 4998 seconds, ncpu: 4, make -j4 > >> > >> So, World+Kernel in somewhat under 22 hours. > >> > >> The "MaxObs*" figures were unchanged, so: > >> > >> Mem: . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki MaxObs(Act+Wir) > >> Swap: . . . , 537588Ki MaxObsUsed > >> > >> This suggests that, for now, 800 MiByte of swap would be something > >> more than 1.5 times what it actually used and 1050 MiBytes would > >> be something like 2.0 times what it actually used, so leaving some > >> notable margin for variations in peek usage, at least when linker > >> threading is avoided. > >> > >> > >> > >> As for what I used to control "what and how to build" . . . > >> > >> # more ~/sys_build_scripts.armv7-host/make_armv7_nodebug_clang_bootstrap-armv7-host.sh > >> kldload -n filemon && \ > >> script ~/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-armv7-host-$(date +%Y-%m-%d:%H:%M:%S) \ > >> env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null" SRC_ENV_CONF="/root/src.configs/src.conf.armv7-clang-bootstrap.armv7-host" \ > >> WITH_META_MODE=yes \ > >> WORLD_FLAGS="${WORLD_FLAGS} UBLDR_LOADADDR=0x42000000" \ > >> MAKEOBJDIRPREFIX="/usr/obj/armv7_clang/arm.armv7" \ > >> make $* > >> > >> (In my context, UBLDR_LOADADDR is ignored by anything that > >> can not use the figure given. So I've no bothered to be > >> more selective about having it in the armv7 builds.) > >> > >> # more ~/src.configs/make.conf > >> LDFLAGS.lld+= -Wl,--threads=1 > >> > >> # more ~/src.configs/src.conf.armv7-clang-bootstrap.armv7-host > >> TO_TYPE=armv7 > >> # > >> KERNCONF=GENERIC-NODBG > >> TARGET=arm > >> .if ${.MAKE.LEVEL} == 0 > >> TARGET_ARCH=${TO_TYPE} > >> .export TARGET_ARCH > >> .endif > >> # > >> #WITH_CROSS_COMPILER= > >> WITH_SYSTEM_COMPILER= > >> WITH_SYSTEM_LINKER= > >> # > >> WITH_LIBCPLUSPLUS= > >> WITHOUT_BINUTILS_BOOTSTRAP= > >> WITH_ELFTOOLCHAIN_BOOTSTRAP= > >> #Disables avoiding bootstrap: WITHOUT_LLVM_TARGET_ALL= > >> WITHOUT_LLVM_TARGET_AARCH64= > >> WITH_LLVM_TARGET_ARM= > >> WITHOUT_LLVM_TARGET_MIPS= > >> WITHOUT_LLVM_TARGET_POWERPC= > >> WITHOUT_LLVM_TARGET_RISCV= > >> WITHOUT_LLVM_TARGET_X86= > >> WITH_CLANG= > >> WITH_CLANG_IS_CC= > >> WITH_CLANG_FULL= > >> WITH_CLANG_EXTRAS= > >> WITH_LLD= > >> WITH_LLD_IS_LD= > >> WITHOUT_BINUTILS= > >> # > >> WITH_LLDB= > >> # > >> WITH_BOOT= > >> WITHOUT_LIB32= > >> # > >> # > >> WITHOUT_WERROR= > >> #WERROR= > >> MALLOC_PRODUCTION= > >> WITH_MALLOC_PRODUCTION= > >> WITHOUT_ASSERT_DEBUG= > >> WITHOUT_LLVM_ASSERTIONS= > >> # > >> # Avoid stripping but do not control host -g status as well: > >> DEBUG_FLAGS+= > >> # > >> WITH_REPRODUCIBLE_BUILD= > >> WITH_DEBUG_FILES= > >> # > >> # Use of the .clang 's here avoids > >> # interfering with other CFLAGS > >> # usage, such as ?= usage. > >> CFLAGS.clang+= -mcpu=cortex-a7 > >> CXXFLAGS.clang+= -mcpu=cortex-a7 > >> CPPFLAGS.clang+= -mcpu=cortex-a7 > >> > >> (I do not claim that you would want WITH_REPRODUCIBLE_BUILD . > >> I just happen to have been experimenting with it. You might > >> not want to be explicit about the cpu to target. You might > >> not want WITH_CLANG_EXTRAS .) > >> > >> # more /usr/fbsd/mm-src/sys/arm/conf/GENERIC-NODBG > >> include "GENERIC" > >> > >> ident GENERIC-NODBG > >> > >> makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > >> > >> options AUDIT # Not enabled by default in armv7/v6 kernels > >> # Enabled here to allow kyua test runs to > >> # possibly report auditing works. > >> > >> options ALT_BREAK_TO_DEBUGGER > >> > >> options KDB # Enable kernel debugger support > >> > >> # For minimum debugger support (stable branch) use: > >> options KDB_TRACE # Print a stack trace for a panic > >> options DDB # Enable the kernel debugger > >> > >> # Extra stuff: > >> #options VERBOSE_SYSINIT=0 # Enable verbose sysinit messages > >> #options BOOTVERBOSE=1 > >> #options BOOTHOWTO=RB_VERBOSE > >> options ALT_BREAK_TO_DEBUGGER # Enter debugger on keyboard escape sequence > >> options KLD_DEBUG > >> #options KTR > >> #options KTR_MASK=KTR_TRAP > >> ##options KTR_CPUMASK=0xF > >> #options KTR_VERBOSE > >> > >> # Disable any extra checking for. . . > >> nooptions INVARIANTS # Enable calls of extra sanity checking > >> nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS > >> nooptions WITNESS # Enable checks to detect deadlocks and cycles > >> nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed > >> nooptions DEADLKRES # Enable the deadlock resolver > >> nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones > >> nooptions DIAGNOSTIC > >> nooptions BUF_TRACKING > >> nooptions FULL_BUF_TRACKING > >> nooptions USB_DEBUG > >> nooptions USB_REQ_DEBUG > >> nooptions USB_VERBOSE > >> > >> The /boot/loader.conf file and the /etc/sysctl.conf files > >> both contained: > >> > >> vm.pageout_oom_seq=120 > >> vm.pfault_oom_attempts=-1 > >> > >> (The hw.physmem=979042304 in /boot/loader.conf was very-special, > >> to better approximate your environment. I also controlled the > >> cpu frequency used via a line in /etc/sysctl.conf . I do not > >> bother with such non-default frequency usage [or related settings] > >> for RPi*'s with the pre-RPi4B style power connections but do > >> control the frequency for the OPi+2E.) > > > > The following had been left implicit about my context and > > how it manages memory space use. > > > > I'll note that I do not use tmpfs or other such memory based > > file system techniques that could compete for RAM/swap. What > > is in use for the only file system involved is just the > > root file system: > > > > # df -m > > Filesystem 1M-blocks Used Avail Capacity Mounted on > > /dev/gpt/BPIM3root 195378 63940 115808 36% / > > devfs 0 0 0 100% /dev > > > > It is a USB SSD. The swap partition is also on that same > > media. (The BPIM3 based name dates back to before the > > BPI-M3 power connection failed and I switched to the > > OPi+2E.) > > > > I'll note that I've started a new from-scratch build without > > LDFLAGS.lld+= -Wl,--threads=1 . So at some point I'll have > > information about how much of a difference (+/-) in swap > > usage it actually made for with vs. without, if any. > > Looks like, for such 4-core contexts, that bothering > with LDFLAGS.lld+= -Wl,--threads=1 is typically a > waste of effort for both swap usage and time . . . > > With LDFLAGS.lld+= -Wl,--threads=1 : > > Mem: . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki MaxObs(Act+Wir) > Swap: . . . , 537588Ki MaxObsUsed > > without: > > Mem: . . ., 715756Ki MaxObsActive, 194816Ki MaxObsWired, 903132Ki MaxObs(Act+Wir) > Swap: . . ., 557208Ki MaxObsUsed > > > With LDFLAGS.lld+= -Wl,--threads=1 : > > World built in 72960 seconds, ncpu: 4, make -j4 > Kernel(s) GENERIC-NODBG built in 4998 seconds, ncpu: 4, make -j4 > > without: > > World built in 72804 seconds, ncpu: 4, make -j4 > Kernel(s) GENERIC-NODBG built in 4824 seconds, ncpu: 4, make -j4 > > > So, just not that much of a difference compared to the overall > sizes or times involved. > A first OS build/install cycle on armv7 (RPI2) using meta mode finished without trouble. Sources were a day or two newer than the kernel, -j4 buildworld took 157121 seconds. Peak swap use was half again as much at 732932. No constraints on ld.lld beyond defaults. I'm a little surprised at the extreme slowness, but this was a fully-debug'd-current kernel and sources were slightly newer than existing world. In case there's interest I've put what log files I could gather at http://www.zefox.net/~fbsd/rpi2/buildworld/main-c950-gff1a307801/ Thanks for your attention and help!! bob prohaska > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > From owner-freebsd-arm@freebsd.org Thu Jan 21 04:46:36 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 81D2A4E9436 for ; Thu, 21 Jan 2021 04:46:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DLqbv2ckgz4s1b for ; Thu, 21 Jan 2021 04:46:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611204393; bh=Q6tdiBSh+pauA23v9tIrkUHL/B4LX3+QPAg65MIhzer=; h=Subject:From:Date:To:From:Subject:Reply-To; b=b8WnBwO06FhSMjlc08nemK5jTsrV4t4MsaNksxyVrBbzRbl7pvEVJPQ3dSVh+p1ThnEYxKvjxu07HXhW1pHsM2z/3s61cUWk5yyRAw/Arl52F/TUEUC8JHHpfIXrfhpr8NGi8kcBo8PDah5ItdqOMwnS7QrJHEYJY3gboIsthXv0NyvYUGYUOHWvBYf/Hoa/bGK1Rs7ea1u7sYwMfeTYVoYrvKTnvouoLIAGyxCFJ7DjFuDLNj+tPgIc4vYS0HzlFVe2Jeogx6MnoNyZD+hRZoJpC+suiyOw8xx6twvJbWUum98CIc6lJX1hWhsvmHmSCbN+VO8z/Hfpkq4HMDdfsQ== X-YMail-OSG: dR.cp7kVM1mrszuCozoPelNESZsn5jRNjG7R9ChN8PFgBRsfj4vUzGa2ThJRjKX Cwf2mB1WBTP6ry16JUN8Q.IfLzl_mTMVYF1TC6w5XGZWoYuqN8kVl9Daew9aL.NSlMxA0pknnKdg biQNiWbkPb_Dkj8ByXKHcINnIBZ5hjOS0Fw6acrwXpi9F7IiKHN9zt9jT4UCAEPysqGSLOYze1Fn 15UaM6pX77M7e_ZpXPZM0SZHRn2zCEmiHTu3ayqkOGE_4KeaDVDPbdJ5vmdIhCAZ0NPdHc9WPu7a PAvhQOrgvh2kidKWwSlMXFhvVDLCYz1C_B4tPOQqArhqiHhBDjJqqvmceAfyvl69A9p.3h9wLSmr HwY0eK7lilD8ABMjiLkIb_55WEacaM7IPikhIMsN8cs0.ST0kjm7mr5CAhyZ3goyOjZH6kr6q7k5 _eaHU1ahJyT9WZh0Ab60KyrJFRVHNJjO5W7Ac7WWHgNfytTbNqQkugg0ujgQOtu7kUdsXVdv9QBx ubKNI.w38FFPmxkqBfkZ3tckoCQ7BDxRoVw_eOp2yf4alewdinHWpT3Ndglnl2_87PsP9aukwdFV 6D3.von5CaGYGDyBDXdmKB6BcVeVQzk1tYwa.H9J__XGPNc2GJopZx3Y02_10B4BIF82pLIXxhX_ 42boNP6tss68SaXNsTE99UFOj9JBLjc4GCKSDIwLLNFeb346q3j4FF0AhxOloHsiKlvmXGXlo3Qo NxNsAdu3DnrMO35483GWSJUNHPvIYNM.i5SlCWE95pwLzxTH8uUskJNpbkYF3DcbMfdpE28bneUK oiLwyu6CMp1hwS6dBSItLyXxEBWcLBlf8t9w_7kp64oSiEALgetkvOYXSaM3KJMcuBWKnQ0a1gD8 GmMDNEL_DRQtGsCxNmM_p.VDP.XBSOOPhiApAlFi1UtvHK_IwACbXVmgdeUYBm9uCp1IZknW5qus ndduKh2lNdnphvmzm3x14bUdMpghhJkNzV6kBxnjON.k8kAVjfLNy1Hhd820MNroWjp0BFjLNs3K O1.CgyZX58hZD.aNH8fsJArhmYuo4x_OHfMQvBvtNVwV_ls18OhI7UpP17JtbPtKdtsyAAgA7mCN LEAvO_IIYVr3y_peOkiVp5WSdnIgZ0YJN3LfjyynjlFuGcoATrcz2O1.koxPEejafDx7LoLdk06H iwjLEgpBG7VkhqoazihQP3lIvzHDAoOb2m47BH7_cBvfwFJZY5ng5G4JZl1vr3jLLQmLvtsNeRSq 7hBTDBRPWC_9o9Ea_f1.z2dw9aW98o_jIwtnb4qDflOnwqIkCmNx93uKUJp5n2OCEbyYm_aGWZtX S8dOLJ42qUrjtlXdyTHrwaje1A8OQOE4gCbtbEqO_BA0UcywSD38kkKDKfD7DD6GR.xaeyYQyEm5 gwCmUUKKJrXFBdPJ0OMoK8EIS.ghW2Uk79.2Luz0KtjeCFwvJmHcEvdXruK1J1bQdQg2gT0MS7r0 UqGf4coEdnFsDsLIllZiQ2nS3TfQ5Ac8VMb4nf8KN8HiOrucoZGesslks166WkSJY3fGeBZDmS.Y iS5w4RRKNq4G7DPd5nH.zZJetx6VyTtopgLxMSUJWiSLZs8gFgrbvCljy9oySC.Jh8IGjV1Ltjnl bjCU.IJbIpXo1zetOEAcGBI3atVmY.849jnt6qdi.BXnqgkVULAxv5CTK6EqJwjDcPdrwkQk7Tnd DSOWA0nPcnfrynG.SfrmxpRatqJbNtSNInZGfn5a.3MyZR37WTLePUKb4S9rvTa3Lv9Y04xTqkCq OpultnUJkNNVm1exjiRzOaeVr5pUScZQayJ5CnK8gC8DxsUZ93MhUPKo3ctwwiyc76TWrIW3JJX7 zscq.m4hCxgba4V1lBwre3.w9y8iMbRuYsd2WvZUWOPqy6UjkhZHBa8AN0TdWPwkEMH38lk2gpDY 5hO4eiWz.xeWQobdK86FZ2ParI9XpBr59QGnTrL3xdU.Pu1_1cAzYrzeeeBoMpo8pKiRHMV6_bj1 Ugy_xxbEkWRDVbDGVK1AwivTn4V6xa_uEH3goGvMFBtq5N7M.128dRWviEhx2V09h8D9rU_c2baq nun8q4iQk9Dfx7kqbHizQyxMddUsQAgoAILSCKzMP2JFOfhN9_W2CuSVyMx0Ufo0KhNmay9FjqTO 3gs.V2FAVjyPZ.znTi6ViaVcyI1p9HLw05MjBi.0lim1Flx_vEnN4EuzsXB4gRW6z6FXy2F_KF6J qgrAU89TDzdSVkra9.8qq.C2Z3WUMKnesczTS4OJ2hqUKV45Ya_0.0KVipnlzWlDeIWGf5rC05ft 0oPLB_iUVXuvG1Pbj508WKd1oTN2tjD9u2k0OB3jREjiPyVTbE3FMEu.6NW7BaMegdyn_LrIIyA7 .nyKMhvmc09s1PoQKWgvv01V5.ZHK.KOvwBpXzSfbkEU.RmA2m7G2k0Dzk8GsIimsTWvkyvIkSFk vXpIAk_RqstMwzBOZzGongsjO_3sd7deLZVDcU_5iEQAV6FAam3NrZrYsj12iM6X5zRycHaCdStP siTpdXHKzoC0fxuP_US2S2mpJwUVOrqRa4eSMcL8xj2gCz8HkILanV9XY1PPYNQTiXVDE.AAQlfF MxPZqLqZw8BvVtW8EuLxX3PODetB4yr8H9euiHYFrc9WXVrAPPYY9N7_TCAI- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 21 Jan 2021 04:46:33 +0000 Received: by smtp425.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 209cfd8f6f68de0991eb03b51cd3fcc5; Thu, 21 Jan 2021 04:46:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <20210121023358.GA58854@www.zefox.net> Date: Wed, 20 Jan 2021 20:46:28 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> References: <20210117174006.GA30728@www.zefox.net> <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> <20210121023358.GA58854@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DLqbv2ckgz4s1b X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 04:46:36 -0000 On 2021-Jan-20, at 18:33, bob prohaska wrote: >> . . . > A first OS build/install cycle on armv7 (RPI2) using meta mode=20 > finished without trouble. Sources were a day or two newer than=20 > the kernel, -j4 buildworld took 157121 seconds. Peak swap use=20 > was half again as much at 732932. No constraints on ld.lld=20 > beyond defaults. I'm a little surprised at the extreme slowness, > but this was a fully-debug'd-current kernel and sources were > slightly newer than existing world. >=20 > In case there's interest I've put what log files I could gather at > http://www.zefox.net/~fbsd/rpi2/buildworld/main-c950-gff1a307801/ The first META_MODE build has no META_MODE information from the prior build. You might want to have META_MODE do a build without updating sources and leaving the existing build materials in place. It would give you an idea of the lower bound on how much time a minimal build would take in your context. On the OPi+2E, for my context, for no linking-thread constraint, an example was: World built in 1468 seconds, ncpu: 4, make -j4 Kernel(s) GENERIC-NODBG built in 116 seconds, ncpu: 4, make -j4 So, somewhat under 30 minutes total. (There can be some things that do get some rebuild activity in such a build. Lots of things can end up relinked, so .full and .debug and such regenerated.) I'll note that for META_MODE to work well, you need to keep using it so that its records stay up to date as a description of the build materials that are to be the basis for the next update. Forgetting to supply WITH_META_MODE would not be good for approximately minimizing the rebuild work done. I've never tried to compare how much more memory is used under a debug kernel than a non-debug one. My use of non-debug vs. your use of debug could explain a lot for both memory use and some part of the time difference compared to my reports. I've only used a debug kernel to buildworld or buildkernel when trying to get evidence for a system problem that was occurring during build* operation(s). QUOTE (from UPDATING) NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: FreeBSD 13.x has many debugging features turned on, in both the = kernel and userland. These features attempt to detect incorrect use of system primitives, and encourage loud failure through extra = sanity checking and fail stop semantics. They also substantially = impact system performance. If you want to do performance measurement, benchmarking, and optimization, you'll want to turn them off. = This includes various WITNESS- related kernel options, INVARIANTS, = malloc debugging flags in userland, and various verbose features in the kernel. Many developers choose to disable these features on = build machines to maximize performance. (To completely disable malloc debugging, define WITH_MALLOC_PRODUCTION in /etc/src.conf and = rebuild world, or to merely disable the most expensive debugging = functionality at runtime, run "ln -s 'abort:false,junk:false' = /etc/malloc.conf".) END QUOTE I was using a 1008 MHz clocked OPi+2E. You may well have been using a 600 MHz clocked RPi2B. I do not know if there are L1 or L2 RAM caching differences involved. There are enough differences to not make the variations in figures from our runs all that surprising. I see that you kept the 2048 MiByte total swap space, so still exceeding the documented recommended-maximum for the context. Since it used under 800 MiBytes, it would seem that it would fit to use more like <=3D1800 MiByte to avoid what the documentation warns about for tradeoffs for having too much swap space. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Jan 21 10:00:18 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 04FE44F0B16 for ; Thu, 21 Jan 2021 10:00:18 +0000 (UTC) (envelope-from olevole@olevole.ru) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DLyYr4pxBz3h9q for ; Thu, 21 Jan 2021 10:00:15 +0000 (UTC) (envelope-from olevole@olevole.ru) Received: by mail-ed1-x52a.google.com with SMTP id b21so1711137edy.6 for ; Thu, 21 Jan 2021 02:00:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZdCsTn5Jx7QMrlWGrLFtObu+iLap51cQaEAgfwPxUdI=; b=pU33MJ2z0DAe/5+L3J5j/isVbxMNeZlg55gOG3x34v91Nd0QhyKGnNXi0+Pl/febyO 3zJsUqEqA515VyyhNU8bcovf63zYgMdnSmzU0eLdtaC1CZKXhkF75yC07pCaauZok6xM clh0JaFuDqGc5rcjHX+Cz3/jS1LeXWm/Iz4wBta4NwPh3XZp1sHDcAlSBRhlGFTQBxkk dx/1DxnoNDNh0N2advlRp/RlCrUGhnXxr45QAXD0JzNje96uC3NsEh97+GwigeGIbmLb QYCytkBV4MRqrYOTbcKkzUk+yXo1FioahEGPhdjHFKWohJNz1iqDvJA3Uo5F4hZSPKEO 4m4Q== X-Gm-Message-State: AOAM532F5ZIVxYTX+X/vXDxqWTGAd3TlAHwKFF2cYvRYNVoG0wgNuZsM LprOPaGnhEi6o7F0VWLlbkFIQGIDZvjDKklQXrVlqVJppe5eKIDZ X-Google-Smtp-Source: ABdhPJylk/OqyrnQZevJCJdrLyyVw7vTMeV1ME2Q3VnNqzs2KZkkXUbiC5PQb3jCVWeOXzAsCuon3SumIJw8yqHfWw4= X-Received: by 2002:a05:6402:31bb:: with SMTP id dj27mr10483387edb.285.1611223214176; Thu, 21 Jan 2021 02:00:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Oleg Ginzburg Date: Thu, 21 Jan 2021 13:00:02 +0300 Message-ID: Subject: Re: FreeBSD on RPI4B: shows an incorrect value of RAM To: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 4DLyYr4pxBz3h9q X-Spamd-Bar: - X-Spamd-Result: default: False [-1.74 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[olevole-ru.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::52a:from:127.0.2.255]; DMARC_NA(0.00)[olevole.ru]; NEURAL_SPAM_SHORT(0.56)[0.556]; DKIM_TRACE(0.00)[olevole-ru.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::52a:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 10:00:18 -0000 > The UEFI/ACPI ( RPI_EFI.fd ) means of booting has the UEFI defaults being to restrict to 3 GiByte of RAM. Thanks Mark for the informative answer! I disabled the option 'Limit RAM to 3 GB' and now my FreeBSD feels good. https://www.bsdstore.ru/trash/IMG_20210121_123742.jpg https://www.bsdstore.ru/trash/IMG_20210121_124352.jpg On Thu, Jan 21, 2021 at 1:25 AM Oleg Ginzburg wrote: > Hello maillist, > > Recently became the owner of an RPI4-B board. Latest FreeBSD snapshot ( > FreeBSD-13.0-CURRENT-arm64-aarch64-RPI-20210107-f2b794e1e90-255641.img ) > boots successfully. However, for some reason, the system only sees 3.1 > gigabytes. > This model has 8 GB of RAM. Any ideas? > > https://www.bsdstore.ru/trash/IMG_20210121_000558.jpg > https://www.bsdstore.ru/trash/IMG_20210120_224751.jpg > > ps: booted from SD via RPI_EFI.fd ( > https://github.com/pftf/RPi4/releases/tag/v1.22 ), config.txt: > > disable_splash=1 > arm_64bit=1 > enable_uart=1 > uart_2ndstage=1 > enable_gic=1 > armstub=RPI_EFI.fd > #disable_commandline_tags=1 > #disable_overscan=1 > #device_tree_address=0x1f0000 > #device_tree_end=0x200000 > #dtoverlay=miniuart-bt > > From owner-freebsd-arm@freebsd.org Thu Jan 21 17:07:51 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 351084D9B35 for ; Thu, 21 Jan 2021 17:07:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DM83B0pCyz4d30 for ; Thu, 21 Jan 2021 17:07:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611248868; bh=UVwxDJ1Q+5Fie1L1RCVhmjnDAe33UP6A7AxH6nYOXGL=; h=Subject:From:Date:To:From:Subject:Reply-To; b=K2oqjLnRXy+9PSvmlZ8TbQxjxzLiIm0z2s+NMppHnwVDX4aRvoJsFi/sJhcvh7xP3tjgZ7cmEjnJJ5mgevwGysgiWK0/ADegakmabna0jYHN0ALD9NJ5Ox7ulhb0vCvkvzP5yDY2SenfeSYhBFn+dKj8K81Z+KtMPbf9hfv0LriL7Ypl1nOC4e4K5dZ6wwKUhILdn+Si7o2w5GT9lKAz7Zug9AbdXqdlXNyPGcgI7YVS1HLhkAa2igiJUWlPwAstf8p/13DgaC4WOw5Est8wn5YS9fDVLlXGIkdT9cbzhFbIOsHV7zmJL/K1Djoum9B9A+NYLOR0LoZ3e29CvQ9UCg== X-YMail-OSG: J3pLBhwVM1nYH.w5nkox7tpZdoCp5h7FuCINiGy_6zPuBSLa2KE__KaWFGRtFZg 4j3hTQZlxGJ4q_6Ohoqb6Hp2X.hxYynfCl_k1lrCwPmy5pqgpOrmrbk86riKsLnmdvWrBiEK6aH4 tcDlyGZ.nJ4BLIf4TrrvodFTM1FJ8KAvyOWlfDCL49tCBoxO5JO.KRs2bDvXX0ALpobFWkFZ7PjJ 3HbzoXWYMbBZ82tAAgkrr.ZldD16o_jueZK5YTmol8i1tdfy.lohobHEXs4JtleeFBVCL_GIA.rF l2yvbrQfOjiAOHt0UbFrHYtOj4FfzVNf91qYND5SYCNs_gBfRjh1CzyZsKQdK8jRtz_0S8peaWSv MyL_Cs1yfAILL4vNZPa4VfxDbIA9yONorXNKWBFYxhHjTS9Rv0bZ05G.2_s9vZ1aJq.UzNsjN21X Wl6nJmvX2h3buFfXzNPTG9miOfVOk6Gb23KbbAqALpVYpaGw09iLKjJ4jqGAJOTdXJy4adw7NgGQ GIbyLhjKLnfdWLw2fbq5WUAb1pOCPfJMPt8RbZeKkMb7ePXJ2y1STxniYSSI6YwyEkOH09XpSOgn Kc4h5YBimSztPK0trPFygsDEYD1jBj3_5q.cjqVNMQ.Nkym2cF_aeISrtiFEin1jQr9W1y1Pq21E XOtgGdOCLyK.nnotGYkJ2wbn7ZCAd8HZqRIAUBgcqiZvr_4YqpIouHPtCESmVlIX56JbjzGJAjTA uSnBDqVtKTxoH_ZywwiVz1cRZi4fh2fzx1Wc655X.SiH.iQujToksuERVLsrobHQHJVOunvO0tbX 8hrJOtykGSaEaZW_NxsQjhikvkABUeVwhvm8ZQvr5wazEtsN7022NAB2pEvXp4YhATtbcESqeGLA m5RiJaReokVXBAm27RjsBq5Y8JRZONdidZkS4uH8aVleBCTYmx.yYYDGvVH1Ki5Io_Dm7fzIdcmI rKqwFURt04po.rfe3OUscHbtoc4JM8HHP2GvZSGKeQlBW25TlfwcXur2hCSkxnoq3zZBKzweUBBd g19bcRphGYMksB_wtwTozI92AW8JeqruPTmoK3jLWiyTlwTOhaPqRRg88sNAxsNxeoeyxQJXs8LE DN6HpO_0vsGEKtWANVU5W73LNrNcl.MSXxsk3JSwMFmq_lSWao8t2z0uBoRUg0aUopGfX.Pun_BG hze0TsgSMYOavQCphz9J9NfDK8Ky9aMBPlVVl._xvdWwJO4Y0Rwv6bjZNaNtU12pdJsbe3dlwY3X 5A_YaF0okyd_aHluVOOVmSBeLxGhk.tBrqLo3MXIPiutoFpvuoEB9kj2Mr0Gmfus4CYjsQAhZlPO O5OCLZTI0hjSC86mru8d65rO.fCRsGTSRjPvvi06w.TkupOCRh26834ZgS1Sm7KUg3.ZiuAUYdvA s0cYGzo.wfiXOedbH5jXdx3PtUenZtJtpUMphf26nRLaFQ53y_.0nYuVLYVj3oGPJIdN1ZSLmN8t u6XuzKkIYtMbCQ8Qa3m.YlFE3lK_ewmNwDBpenPAHJZn9f30bJBrvOJoVAKM5YdyS.9NT2_myZEq UABxRWfGXIY7S7XRJhFdm_uRxddFFkmVJDdMVHgzZr7hhUCPB5sXde90cmbIPxu8p9uItShnaI4I gpAqkcbIJOGMED5u8Wq7fix5Qv6GBS81Xf8SwTbWT8ZeTTBNG.hz0lwanGld4rAhJMt_i4ZevCSn gNRopcZFzLJt.T0ICbZh6wQUH4tVyxECjqs5gvKvSrdgERmaNsxTfG8oUZnKsfPpaGM_Y4WKUasg NGiGdROgu0eOvcYdP1MAvdl8DNVF5RZMHsPRuFGx3dA6q8jp2Yi6gKRIjFEmlLoZtWcEQAHUYDXE LYS0KfEMbOdDT316e.y.gTX6hQPYoC_tLwb2xvSzYLFxdkwvlbxNKMZWDcSegz71k1sEEJzfBCOn mMLGUCm5FQf4yrC9p5byZcOqqRgnV7cu8Ow8v266azYjKPEasRA3j6z45FQQcJZEliU0R_JsKytF xc0Gh6SwC3r9PyD2uaeiiauRu5r1OdcrSH7b1ZGHnLMNf1MsTpT5XXHqafoYuqOvrRXaODdYpxX4 SMFyevxw5vXrSYc26Z_BRUxLBncb4W9THMizyuVy1tfSI6hp7.qhc.VQ8qojRW_VjqeKZ8qaOu7I s22lCRxJZrLrCJYSlHp4y9ZPNAH3oS8SLYeOUW3WXJfvh7j1CAobQFQ2bN96To50urJeP.8jpJ1u wZDNc061tbcv5nVgBmwzMFQmVefvDTTeZ13ETVFG.mntHLhLUVflnBYVa6y3GYagIlmHLSr1DwS7 M.X8HliXmv0rG6_r1NoCA6xgbTeGjgRMbxFxO364XuL.VP6EmcT1UPDH1kbYVH97X5NOHL_1KZ0e PD7YOzjNqyUX7OkAMniK1mRFegrj62UTKzbx6vta4tex43YZQRw__gBezyAX.YPHnhTLcr.Z8pxF cEeQ1._iB_IX1bflkE5cK Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Thu, 21 Jan 2021 17:07:48 +0000 Received: by smtp417.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fbd3e11bd848f4b9990151662ad53d73; Thu, 21 Jan 2021 17:07:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: FreeBSD on RPI4B: shows an incorrect value of RAM From: Mark Millard In-Reply-To: Date: Thu, 21 Jan 2021 09:07:42 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Oleg Ginzburg X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DM83B0pCyz4d30 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.31:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.31:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 17:07:51 -0000 On 2021-Jan-21, at 02:00, Oleg Ginzburg via freebsd-arm wrote: >> The UEFI/ACPI ( RPI_EFI.fd ) means of booting has the UEFI defaults = being > to restrict to 3 GiByte of RAM. >=20 > Thanks Mark for the informative answer! > I disabled the option 'Limit RAM to 3 GB' and now my FreeBSD feels = good. >=20 > https://www.bsdstore.ru/trash/IMG_20210121_123742.jpg > https://www.bsdstore.ru/trash/IMG_20210121_124352.jpg [I presume that you have not patched FreeBSD to deal with what I reported about unreliable operation for > 3 GiByte RAM in use.] You have made a configuration for which FreeBSD is demonstrably unreliable: copying (duplicating) a sufficiently huge file and then comparing the two files will fail to find that they match. Small files can also have such problems but most will not. (Small files is how I first found the problem.) Expect failures from corrupt files to sometimes occur in the configuration you picked to use. > On Thu, Jan 21, 2021 at 1:25 AM Oleg Ginzburg = wrote: >=20 >> Hello maillist, >>=20 >> Recently became the owner of an RPI4-B board. Latest FreeBSD snapshot = ( >> = FreeBSD-13.0-CURRENT-arm64-aarch64-RPI-20210107-f2b794e1e90-255641.img ) >> boots successfully. However, for some reason, the system only sees = 3.1 >> gigabytes. >> This model has 8 GB of RAM. Any ideas? >>=20 >> https://www.bsdstore.ru/trash/IMG_20210121_000558.jpg >> https://www.bsdstore.ru/trash/IMG_20210120_224751.jpg >>=20 >> ps: booted from SD via RPI_EFI.fd ( >> https://github.com/pftf/RPi4/releases/tag/v1.22 ), config.txt: >>=20 >> disable_splash=3D1 >> arm_64bit=3D1 >> enable_uart=3D1 >> uart_2ndstage=3D1 >> enable_gic=3D1 >> armstub=3DRPI_EFI.fd >> #disable_commandline_tags=3D1 >> #disable_overscan=3D1 >> #device_tree_address=3D0x1f0000 >> #device_tree_end=3D0x200000 >> #dtoverlay=3Dminiuart-bt >>=20 >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Jan 22 01:15:37 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5109E4E6C80 for ; Fri, 22 Jan 2021 01:15:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DMLsz4pQkz3kJN for ; Fri, 22 Jan 2021 01:15:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 10M1FaZL066866 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 21 Jan 2021 17:15:36 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 10M1FZVD066865; Thu, 21 Jan 2021 17:15:35 -0800 (PST) (envelope-from fbsd) Date: Thu, 21 Jan 2021 17:15:35 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld Message-ID: <20210122011535.GA66611@www.zefox.net> References: <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> <20210121023358.GA58854@www.zefox.net> <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> X-Rspamd-Queue-Id: 4DMLsz4pQkz3kJN X-Spamd-Bar: - X-Spamd-Result: default: False [-1.07 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.970]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 01:15:37 -0000 On Wed, Jan 20, 2021 at 08:46:28PM -0800, Mark Millard wrote: > > You might want to have META_MODE do a build without > updating sources and leaving the existing build materials > in place. It would give you an idea of the lower bound on > how much time a minimal build would take in your context. > On the OPi+2E, for my context, for no linking-thread > constraint, an example was: > > World built in 1468 seconds, ncpu: 4, make -j4 > Kernel(s) GENERIC-NODBG built in 116 seconds, ncpu: 4, make -j4 > > So, somewhat under 30 minutes total. > > (There can be some things that do get some rebuild activity > in such a build. Lots of things can end up relinked, so .full > and .debug and such regenerated.) > > I'll note that for META_MODE to work well, you need to keep > using it so that its records stay up to date as a description > of the build materials that are to be the basis for the next > update. Forgetting to supply WITH_META_MODE would not be > good for approximately minimizing the rebuild work done. > > I've never tried to compare how much more memory is used > under a debug kernel than a non-debug one. My use of > non-debug vs. your use of debug could explain a lot for > both memory use and some part of the time difference > compared to my reports. I've only used a debug kernel > to buildworld or buildkernel when trying to get evidence > for a system problem that was occurring during build* > operation(s). > > QUOTE (from UPDATING) > NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: > FreeBSD 13.x has many debugging features turned on, in both the kernel > and userland. These features attempt to detect incorrect use of > system primitives, and encourage loud failure through extra sanity > checking and fail stop semantics. They also substantially impact > system performance. If you want to do performance measurement, > benchmarking, and optimization, you'll want to turn them off. This > includes various WITNESS- related kernel options, INVARIANTS, malloc > debugging flags in userland, and various verbose features in the > kernel. Many developers choose to disable these features on build > machines to maximize performance. (To completely disable malloc > debugging, define WITH_MALLOC_PRODUCTION in /etc/src.conf and rebuild > world, or to merely disable the most expensive debugging functionality > at runtime, run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > END QUOTE > > I was using a 1008 MHz clocked OPi+2E. You may well have > been using a 600 MHz clocked RPi2B. I do not know if there > are L1 or L2 RAM caching differences involved. > > There are enough differences to not make the variations > in figures from our runs all that surprising. > > I see that you kept the 2048 MiByte total swap space, so > still exceeding the documented recommended-maximum for > the context. Since it used under 800 MiBytes, it would > seem that it would fit to use more like <=1800 MiByte to > avoid what the documentation warns about for tradeoffs > for having too much swap space. > For the time being I've reduced swap partition so the system reports Device 1K-blocks Used Avail Capacity /dev/da0s2b 786432 0 786432 0% /dev/sdda0s2b 786432 0 786432 0% Total 1572864 0 1572864 0% That should somewhat reduce suspician that too much swap is the culprit when something unfamiliar goes wrong. For the sake of my own understanding it would be useful to provoke a failure attributable to excessive swap, just to see if it's specifically distinguishable.. My puzzlement over the long compile time was motivated by memories of early experiments building world on a Pi2 v1.1 using the same hard disk. Those took around 24 hours to complete, both world and kernel IIRC. It's a bit grim to see apparent performance decrease over the years, if in fact memory serves accurately. Since I didn't keep the various test results it's impossible to verify whether I was using -current or -release. Thanks for reading, and a great deal of help... bob prohaska From owner-freebsd-arm@freebsd.org Fri Jan 22 05:25:44 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 605C94EA6AA for ; Fri, 22 Jan 2021 05:25:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DMSQZ3J6Hz3w4b for ; Fri, 22 Jan 2021 05:25:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611293140; bh=Y9UbdF5nllyIozZ0H5mDB/2WsqBZjyeD62UlQs5G6HT=; h=Subject:From:Date:To:From:Subject:Reply-To; b=CaCTQAC71GHNojQ8Hk7hel2CJoaZfTV44IFATdBCNTcYbN0zpEXJ6qHAjrJxlXvnBys54x7SA1Y6XSwJQaEphI74YtqZPdoAkg7NzFSSVHBVaoSCIA2nlDBy5Pdc+zIge04BciaRaeHed3bzuct+eb1IhmEyvzmiBlzu4kj6kEMdChHoKS16BkZ/UT7v0N3FTBtgWqjLjM6/KoUjLAhDdSjk/Li+OBQMs2xRVsbG3jcnISnv/EBV1tF/3yuKGNg0zYQKt/RMy1DGW9mhjOxwz8Fi1BYmCjJvtA3+hT12eKftNcA/OCxWxGpIdWl5NbMOu6X6glwGdBklSliYSnBsag== X-YMail-OSG: uIJPxBkVM1m8a8TZoWwx4TGtFGI8CLnGvqNDTjo9wFrIzoWxexx3xm6zKIrsoGc _J7sMCMNL93yc3E3iq3tfm4WGNM_JlMxuoeMtEEL63bHXUDpiJGds30O1wGFUDRYhyurGKfZppw2 REDlVBXmLlDJGQFPXko.Sj7FCS0KxfE062ZUGfKbcnfKG_BTwgY3v0K4CCGADChhogN9w6BpgcMU QSKvzO612ol_tU0cCDlHhV0uyLCOwxpMQuR8ipXuAAjylePvVAO28UHvdMsFkSMOnYiOL24IyLyd MXBQMomZDypFB7DlnswrUJ7WJgrfMNu5sS7KaszWz2aETTiZqo5PSVpSQB4WU8bLDGVihvCVLqTi Rw.WpWEcR2.t7eRIMRtXoypd3Tyt.palM3Fw7NGC1wooihuLtD77gLNwBeqxzLqUri6TIfT_dzYP hYN2PEWtz_H3PS8li.EidcdV8e20r4LfsVksFlDtDugFJ6qCwg1GUqtPgJ2zPeP816mLbch3T_kS OMMG_na7BxAXGS8jYpEWwr2qRNsPIGZGyYohfgUDhOpKPvvhcwKh9xd7A9_784RQ2GTC2ntBSs2D AEK7FSywdL91fyMDVZWm2Pf..lNisgNYVT0PYjoK0FqKkc1QYMOpTFSFoVaxSojTmoyHBjznnEk1 FU5eBN.DtP1qsT.oYRuULKMdIOb4XyVT3p9qcOvfZRwNPQe3Q1qoxQxxEoaNE4At3mj.dEvu2yJA qUO0e5SX39X9kP8DfjmMlSd6M3bPJoi5hkoksh1KZMUf9Y3Mn.fhL06Be1XtM_C8Jw5I4ehKndS7 qfvdj4mTf._19mmTzUATpG6snMetqatPATYDePOCT3BHFJlknsqmyec3.gVMnIDji2UmUjO_tHVr ipZ4kUS0ze7WeHnlQzvSORv0mDYm.Sw0sIM1nSbvCRHldtObNXLMyCGNkHSK0ZcL.ezcrcSieUUz 9SNqHMpsL9Nrd_KWgUiEiobUZdRDE2A03ofQxTYHXARgLb2NEvuHol67c1yCzR4GhHEhhVkZkZU5 TmESKzqHmmiPuU9elOxPI6c_IeIiYSQaFKdxMpdJjfJEqWXFbcbmS9RCJXc3QmJ9bC1g4zAfoMDi pXcSpn_uvnNpsZwEA1BBKXhRkvCVlbOX8dHSgrPeCPa_VXPC6SZB6.GJ1fRChzKQ24q_N2.MRjtl ZiWA0KC7LDaHmrApaEVWspWM64tGaxfrDbDQSuu3otzd5gaEOwg.BbkJh3pHK6OHwaLbzzKfKJq4 UClv_otAng93UXZ8wDf0fmdCvUC7a5kTM6nMsxqXyBoW_QYwGqNyq7u1rzIILsXsNzurV1UIq4XO wcki117NHIQOL_f71akodBB8K92j0YbsQksV4If50Hu5ckwnGD5eBNJps0MQhTdMrgjiJseT7hnY ohhyPWLHLKpM6zf5jorLqaCX9z02RMMHsFhVuT6Lz6tjCxljpqymswTneayZ07AxIBZwd.pyro4V nzTTmfXZLA5gOUVDW2_rFEGsY2dZH0VtE.ZvUs.jC.IFIWHHMCLlQQMw3v3QBsWQtjvxsjmPWySq uLBGsRb1al3UcKgvyE2CMgBZmqO7ATNPdAfN0YZhaDzB9nJy.2WfWLVu_278QdIzeSkOixnBfL2e YqHzyfJBcuxyVNPcok9dRBzye6PyEu8K9koaWhUpRLsW8zUnNO91weh.JRee.8NLyQdxybEGYEiM j2OZ8CxetDpGD9AcjDeryL8ifSIWEDWTo0_qYOpZuIGFtLTIC6srjwVbuKUJUTrwSlH1lGPyoXjL UqrqTYPwZogffEgTQeoRfSNihd5kPW6qB0yWlr4KcVCQI75dU53HYHE8aHKvBopIuukXmNAf_a3b gl0KM5OxSYPRFBUCZozpVwTWvNRmAFAEUXVGask_CjyZxcEFib0iiXyWnFdScthhpu5JmzDbo7Nx QU.Z_G1UN0YmLMlywRPoDVutBMhQga1uZzsufbGxMdEFJN_MiiB18Ka4F.RW9oLLVRcPTnGXvtRD IwwpdCHB41xNxidRpCr81CYZU0GBx1TuROsm01o6jMFvAeZeSXyfDjFbVcsnwOSFurnYnfOK4is2 6V1OU_Uu4wU4BX.7CA1jRj5LXSiGf15dke9utkEPz0y1_rC5doBJa5scmgeK04k31Ch_Ebx2JIhr swPhO3H.kZmkP8Y.89Sh02CGsK4krCoe3GkNPjYanaUGycszcrV4SG.LJ8YyqCZsK1oLWHplSdqh GaFgb8ixuvB_2Rkhe1nELZF9YTJmWoPI5Aub1VRA8GZosLOGj6MG0sRYrr8Vo4xiB6S7Cwien.gA Lv.2lxGq8xTD.e30rPxCr5ewiLHCd9f9zidvkW63xVL8_vbn_TXfr25FjsFDLJsxjMWYs35cY1Cs QlWwerZGLM3ok3pJuTYTyAKiHlcKorHQJe_MhqVdnHVPB.gpNTpIX2p5J_lhiSM3Sh_y16vZRnVQ 9yiE0JFqbtJBp6m.IXK.kqsRq99_Y5fP5ZYlv06r0rN0o3SA_fnKwpR7q5DuBDJNghZsdDQLObmy JvwUyRKXANRf_fZX194J9oaKPX4gmUWKimN8UqjU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Jan 2021 05:25:40 +0000 Received: by smtp407.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fed2b8747f8d87e3fe2473acc1f799bc; Fri, 22 Jan 2021 05:25:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <20210122011535.GA66611@www.zefox.net> Date: Thu, 21 Jan 2021 21:25:34 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> References: <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> <20210121023358.GA58854@www.zefox.net> <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> <20210122011535.GA66611@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DMSQZ3J6Hz3w4b X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 05:25:44 -0000 On 2021-Jan-21, at 17:15, bob prohaska wrote: > On Wed, Jan 20, 2021 at 08:46:28PM -0800, Mark Millard wrote: >>=20 >> You might want to have META_MODE do a build without >> updating sources and leaving the existing build materials >> in place. It would give you an idea of the lower bound on >> how much time a minimal build would take in your context. >> On the OPi+2E, for my context, for no linking-thread >> constraint, an example was: >>=20 >> World built in 1468 seconds, ncpu: 4, make -j4 >> Kernel(s) GENERIC-NODBG built in 116 seconds, ncpu: 4, make -j4 >>=20 >> So, somewhat under 30 minutes total. >>=20 >> (There can be some things that do get some rebuild activity >> in such a build. Lots of things can end up relinked, so .full >> and .debug and such regenerated.) >>=20 >> I'll note that for META_MODE to work well, you need to keep >> using it so that its records stay up to date as a description >> of the build materials that are to be the basis for the next >> update. Forgetting to supply WITH_META_MODE would not be >> good for approximately minimizing the rebuild work done. >>=20 >> I've never tried to compare how much more memory is used >> under a debug kernel than a non-debug one. My use of >> non-debug vs. your use of debug could explain a lot for >> both memory use and some part of the time difference >> compared to my reports. I've only used a debug kernel >> to buildworld or buildkernel when trying to get evidence >> for a system problem that was occurring during build* >> operation(s). >>=20 >> QUOTE (from UPDATING) >> NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: >> FreeBSD 13.x has many debugging features turned on, in both = the kernel >> and userland. These features attempt to detect incorrect use = of >> system primitives, and encourage loud failure through extra = sanity >> checking and fail stop semantics. They also substantially = impact >> system performance. If you want to do performance = measurement, >> benchmarking, and optimization, you'll want to turn them off. = This >> includes various WITNESS- related kernel options, INVARIANTS, = malloc >> debugging flags in userland, and various verbose features in = the >> kernel. Many developers choose to disable these features on = build >> machines to maximize performance. (To completely disable = malloc >> debugging, define WITH_MALLOC_PRODUCTION in /etc/src.conf and = rebuild >> world, or to merely disable the most expensive debugging = functionality >> at runtime, run "ln -s 'abort:false,junk:false' = /etc/malloc.conf".) >> END QUOTE >>=20 >> I was using a 1008 MHz clocked OPi+2E. You may well have >> been using a 600 MHz clocked RPi2B. I do not know if there >> are L1 or L2 RAM caching differences involved. >>=20 >> There are enough differences to not make the variations >> in figures from our runs all that surprising. >>=20 >> I see that you kept the 2048 MiByte total swap space, so >> still exceeding the documented recommended-maximum for >> the context. Since it used under 800 MiBytes, it would >> seem that it would fit to use more like <=3D1800 MiByte to >> avoid what the documentation warns about for tradeoffs >> for having too much swap space. >>=20 >=20 > For the time being I've reduced swap partition so the system > reports > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 786432 0 786432 0% > /dev/sdda0s2b 786432 0 786432 0% > Total 1572864 0 1572864 0% >=20 > That should somewhat reduce suspician that too much swap > is the culprit when something unfamiliar goes wrong. For > the sake of my own understanding it would be useful to > provoke a failure attributable to excessive swap, just > to see if it's specifically distinguishable..=20 There may well be ports that just take too much memory for an RPi2 v1.1, even for -j1. aarch64 is more appropriate for when larger swap spaces are required: they allow much more swap for the same RAM size, even while staying in the tuning range that applies to them by default. True even of the RPi3 booted for aarch64 use. There may be ports that take too much memory to build on aarch64 with only 1 GiByte of RAM. Others may sometimes build in configurations were failure leaves questions of mistuning being involved. > My puzzlement over the long compile time was motivated > by memories of early experiments building world on a > Pi2 v1.1 using the same hard disk. Those took around=20 > 24 hours to complete, both world and kernel IIRC. It's > a bit grim to see apparent performance decrease over=20 > the years, if in fact memory serves accurately. Since > I didn't keep the various test results it's impossible > to verify whether I was using -current or -release. You wrote about a RPi3 (not RPi2) -j4 build in 2018, note its buildworld time frame: QUOTE A clean-start -j4 buildworld was run using four swap partitions. = Buildworld finished in about 26 hours, so the added swap did not speed the process=20= compared to a single microSD-based swap setup. Total swap used peaked at 1321024k. END QUOTE Note that now the swap use is less than back then, FreeBSD having avoided some -O2 related compile time/memory-use issues in more recent times(?). (I do not know the armv6/armv7/aarch64 booot type status.) An RPi2 stable/11 buildworld quote (2017) is below, note the total swap configured compared to modern requirements (the text is from a crash report so the time is not relevant): QUOTE last pid: 30305; load averages: 0.00, 0.38, 1.51 up 0+07:38:08 = 16:55:41 48 processes: 1 running, 45 sleeping, 2 waiting CPU: 0.1% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.8% idle Mem: 751M Active, 29M Inact, 135M Wired, 88M Buf, 8K Free Swap: 256M Total, 64M Used, 192M Free, 25% Inuse QUOTE Apparently the clang4 related toolchain was before things caused you to use large swap sizes --or you had not yet tried large port builds yet. This was back in armv6 days. (You reported that you used a file-based swap back then, a possible cause of hangups.) I did not find anything directly on point for your old RPi2 experiments. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Jan 22 05:47:29 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6EB1E4EAE6C for ; Fri, 22 Jan 2021 05:47:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DMSvh27B8z4R9r for ; Fri, 22 Jan 2021 05:47:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611294446; bh=k0NZbzGEv6iqWU1LpAKrRs7h5mUVBrMQeyosjs0P2bs=; h=Subject:From:Date:To:From:Subject:Reply-To; b=ed6lrtmX29ajMsTfTdKLJnckCWfdFrhK6bJlxZ96j+DWaxZHgmYtzGqUafBSgAW+0/4SqCjKqyiDeh6f2u4759lUD6RWJ6CNndHKc9S29U8daAkHQd3Ww3pZeD7ptbQw7z/IJDYTOjZibtPisw0Q+j0EiIfn93RkU5bMQ4G+ntLn7cOnOdIznmb4my9zLPU7OWm5SE14byqUe7rp0M57bLNHjStb2/plcpK//ZZJJJFS0CHcDDkB6iNKPyUpUJ+RY0zusdU42M1OjTos8eqe6WBKMf+pwt9BGb2aD/6Qnj62wMcRMIRJHwILTj/2QOcujKGAvNiCLKtGsVBTbjnJvA== X-YMail-OSG: bcCIFqgVM1k5rQutXkxwWfdsVkOClPcMGF3aFiwJhm7rqUuxk_C.m.6ejhtTKz9 fK7g2xDj9V5x86y6RMPDVzE9iCQqt4aJHoI1Nn2tHUL5dKf8LGrtlNjOLmDP1OLFomTF23UDCrTX g1M8GuK.Oh5b6bo5ukfIRypoU56PtNOuO9RVB7RAWLgY2FhIif.mv3diJprinSi00ZFmhF3EXPJT Wfyk63AVUtrL39MEHdyAyGAMncSDmnlmRgzsYAW759LIME8FJ67VGmnP48_U3wis0Z3D91VKAqDd xwJjjHwRZ2USOS_WTtKoPX45tVsZDiH8E08Dkwy1z6ESyCDpiUbAfVOBR04esrJhYHkOL3HcCcH5 ch5lrZ1O8AphwpXOL1X1dnd9eeNez83CNL_WWPCoYeKg8495k7SBwImlAC_3_uEBXfzZpdB0IMFY oq.E.sE4rDcqZkGI2Es0pJ_84vgMmO5J6VC84c7HykjXWs.VQfgXohlxx5Nc6mi1Zl.1etIAApVn 5sInTiBBJOjXH96F3bfzRh.pmUttHqkOCHAkHh1N50ywWbJgfOXF1Z5OBvy3n_REUpzw_gohg3Pu AsLu9qZKAgH.GBqu89WCPvCdiYVXV2bBzL38Ft6e3IRimsBj4yytlOHYZrGi5eqqxUlZo5yywtK5 LH9tu1_AK.oVQhE8NvE1ZbGdU6hs7vkLvwNIwDre5SPKH8Es8IVTMw8eFFfdLjXEiLM30CAq_Snt sMwhgMqO_es1m3TuKMlebku2A3b.4B4icDO2i3A3vv2w0lYZ.jcA6jP3dixIeMTHiN1jVyo8BjDA M9skc.7x2QI22tpkui6GvAtgzMp9.ghL1Rbp2mFLusANsU5RfP7DGIv9w9JfIoe2EkV2ZQWaHOy9 cbJk4rF6YtnVXKQ3gPEe39xsOM1M723luty.Lpqt2dGeePSIlc0JukybdzAkNrXGlPvemBXxznIv tAiqWMJ6Me3ADEaDiRgftDHmYDPexKnZrsxjYrXCnhgTkTfKO4sPe6YSWqg6Cs.F3M2.Ja4KQnpa bYY0cITi5quqkYhqAQNDC2QWA6l1BuYy8rOVBaRPby3yitsKYrkafRF7PQoEngKLO.n07yuOmIy7 241bxDmr_aIzh_15QHFqG_dSHHy0MvbEx4XVf1UyEolkuyTb96xP3rQFocgno8gbfXKSJLYGRttA 9uPIllkANUSaT1daWGD4cq7Zt7DQwyweEhMAolD94pniNQm2Q0ZFCNaQV7M5R330UGSLSdbiJZxB TN9kzB1XvRhSwiCuDWxueHr1uGoRrWrIZaT1j1l_2ewdXi252nuLyOYD_ViP2ueYn8sC8jYB6rm7 .rVEAZBeY_1hDbG0HySAelIhznORqsd1p.6aF0TgBvMaEuorgzWO1UY3Eq7YBjn7zVqhIwYh3DOg eG2U1BgYZIkw1.v6LiK8NH8so0YdB9owPNij8a70hhia57dH9sNHFEXy9CzIBN9GPV3pCJE6PJtX vjQF7ckKFo9lVgf8gqARIDlsPePTwp7RR4bfwrnmxxpTjJfnXtMdH_lR30WiYGFtPCo2HXBoYQvw hduiDStDb8Bd.H.k2FLko1oH5lS0Do_2C17EnAGbJGBxseWBT5ZdahyZr.6D_rFRo.DBxkPc3jzt AJFQLkTNIs5jc2OXKhV8m_Oz7tSJ0evbSDms3q6M0U81MTjT9MPtx0LRapcfR4.9Uoyl8qy4ipT1 r3aZEcE.CtgW4sgfuu.i.971xBgDDx_VTdSlI3oxzeNlyPY1rzSUnsmg96B4no7ILgyx60QWkzKU 4zk2owvbYzcqnlmKJMegYF3wBSfZcwK3__uXl29m_WhGnpu38F7HNB5q3R_RCjMof6lB3r23ubxc fsYa_2MlWRrKqQhy7QwTCokxg7A_G.D2w8ZLK1wMcImmrntoElh6vyaTC6ALwqhk4xWy8axxkxzb bPWwZV3B7q1aX4sL._yTxjnIZXznt2hBEjmOFqt.eCv.kN01KmsylW7u064AlrKPTqi127mZTGPw .RqyOKgxGyqMmv8d9sHKDZvQ0tqKMHpqHwPIfHW4FGXY1v.Ol_Qlc6cwIH.BNrv5oa43jwQBtV3h ADPJwwcjx8TxsLN9jLh8o30QLi7cspRla0qR7lO2ZH0KuDMwJx.JJMv3wPy3dut0lzUnFQcoXO8g yfhTmcbxwUJvMQHKb.peI6MR7qowaOR65dkvJatdnAko.5tx9JS4L6n7gWApPW_9126SyTRl0rg1 fcWCmLsSTAxIhk4db6wOn.m6DEOadMVsMY4AfiFPzgQuYzVvxDo_HhStZQzty8nXcRQaz5lirY.Y e5oN8z9ASkbQakRHSCtWRwmclOwgLvpRMi_aRP_h9Ge.RBfZ5KQiWm6QIV3G4CD41N7YeaqMG1Dw GBtOnfcsrHHBjxmu.cQ65z06srYB_I7rd7qvtMCVygFTaZVW6j6kYZELfw26uqQweoxlAT5jdJqI jso0VD5kcbrPvcWv2pK9uMgvStJTl8c3EFfYqSARylSho6Y86efpGpUY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Jan 2021 05:47:26 +0000 Received: by smtp423.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a925a8bba8b85f2e5664050205d674dc; Fri, 22 Jan 2021 05:47:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> Date: Thu, 21 Jan 2021 21:47:25 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> <20210121023358.GA58854@www.zefox.net> <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> <20210122011535.GA66611@www.zefox.net> <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DMSvh27B8z4R9r X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.206:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 05:47:29 -0000 On 2021-Jan-21, at 21:25, Mark Millard wrote: > On 2021-Jan-21, at 17:15, bob prohaska wrote: >=20 >> On Wed, Jan 20, 2021 at 08:46:28PM -0800, Mark Millard wrote: >>>=20 >>> You might want to have META_MODE do a build without >>> updating sources and leaving the existing build materials >>> in place. It would give you an idea of the lower bound on >>> how much time a minimal build would take in your context. >>> On the OPi+2E, for my context, for no linking-thread >>> constraint, an example was: >>>=20 >>> World built in 1468 seconds, ncpu: 4, make -j4 >>> Kernel(s) GENERIC-NODBG built in 116 seconds, ncpu: 4, make -j4 >>>=20 >>> So, somewhat under 30 minutes total. >>>=20 >>> (There can be some things that do get some rebuild activity >>> in such a build. Lots of things can end up relinked, so .full >>> and .debug and such regenerated.) >>>=20 >>> I'll note that for META_MODE to work well, you need to keep >>> using it so that its records stay up to date as a description >>> of the build materials that are to be the basis for the next >>> update. Forgetting to supply WITH_META_MODE would not be >>> good for approximately minimizing the rebuild work done. >>>=20 >>> I've never tried to compare how much more memory is used >>> under a debug kernel than a non-debug one. My use of >>> non-debug vs. your use of debug could explain a lot for >>> both memory use and some part of the time difference >>> compared to my reports. I've only used a debug kernel >>> to buildworld or buildkernel when trying to get evidence >>> for a system problem that was occurring during build* >>> operation(s). >>>=20 >>> QUOTE (from UPDATING) >>> NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: >>> FreeBSD 13.x has many debugging features turned on, in both = the kernel >>> and userland. These features attempt to detect incorrect use = of >>> system primitives, and encourage loud failure through extra = sanity >>> checking and fail stop semantics. They also substantially = impact >>> system performance. If you want to do performance = measurement, >>> benchmarking, and optimization, you'll want to turn them off. = This >>> includes various WITNESS- related kernel options, INVARIANTS, = malloc >>> debugging flags in userland, and various verbose features in = the >>> kernel. Many developers choose to disable these features on = build >>> machines to maximize performance. (To completely disable = malloc >>> debugging, define WITH_MALLOC_PRODUCTION in /etc/src.conf and = rebuild >>> world, or to merely disable the most expensive debugging = functionality >>> at runtime, run "ln -s 'abort:false,junk:false' = /etc/malloc.conf".) >>> END QUOTE >>>=20 >>> I was using a 1008 MHz clocked OPi+2E. You may well have >>> been using a 600 MHz clocked RPi2B. I do not know if there >>> are L1 or L2 RAM caching differences involved. >>>=20 >>> There are enough differences to not make the variations >>> in figures from our runs all that surprising. >>>=20 >>> I see that you kept the 2048 MiByte total swap space, so >>> still exceeding the documented recommended-maximum for >>> the context. Since it used under 800 MiBytes, it would >>> seem that it would fit to use more like <=3D1800 MiByte to >>> avoid what the documentation warns about for tradeoffs >>> for having too much swap space. >>>=20 >>=20 >> For the time being I've reduced swap partition so the system >> reports >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 786432 0 786432 0% >> /dev/sdda0s2b 786432 0 786432 0% >> Total 1572864 0 1572864 0% >>=20 >> That should somewhat reduce suspician that too much swap >> is the culprit when something unfamiliar goes wrong. For >> the sake of my own understanding it would be useful to >> provoke a failure attributable to excessive swap, just >> to see if it's specifically distinguishable..=20 >=20 > There may well be ports that just take too much > memory for an RPi2 v1.1, even for -j1. aarch64 > is more appropriate for when larger swap spaces > are required: they allow much more swap for the > same RAM size, even while staying in the tuning > range that applies to them by default. True even > of the RPi3 booted for aarch64 use. >=20 > There may be ports that take too much memory to > build on aarch64 with only 1 GiByte of RAM. Others > may sometimes build in configurations were failure > leaves questions of mistuning being involved. >=20 >> My puzzlement over the long compile time was motivated >> by memories of early experiments building world on a >> Pi2 v1.1 using the same hard disk. Those took around=20 >> 24 hours to complete, both world and kernel IIRC. It's >> a bit grim to see apparent performance decrease over=20 >> the years, if in fact memory serves accurately. Since >> I didn't keep the various test results it's impossible >> to verify whether I was using -current or -release. >=20 > You wrote about a RPi3 (not RPi2) -j4 build in 2018, > note its buildworld time frame: >=20 > QUOTE > A clean-start -j4 buildworld was run using four swap partitions. = Buildworld > finished in about 26 hours, so the added swap did not speed the = process=20 > compared to a single microSD-based swap setup. Total swap used peaked = at > 1321024k. > END QUOTE >=20 > Note that now the swap use is less than back then, FreeBSD > having avoided some -O2 related compile time/memory-use > issues in more recent times(?). >=20 > (I do not know the armv6/armv7/aarch64 booot type status.) >=20 > An RPi2 stable/11 buildworld quote (2017) is below, > note the total swap configured compared to modern > requirements (the text is from a crash report so the > time is not relevant): >=20 > QUOTE > last pid: 30305; load averages: 0.00, 0.38, 1.51 up 0+07:38:08 = 16:55:41 > 48 processes: 1 running, 45 sleeping, 2 waiting > CPU: 0.1% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.8% idle > Mem: 751M Active, 29M Inact, 135M Wired, 88M Buf, 8K Free > Swap: 256M Total, 64M Used, 192M Free, 25% Inuse > QUOTE >=20 > Apparently the clang4 related toolchain was before things > caused you to use large swap sizes --or you had not yet > tried large port builds yet. This was back in armv6 days. > (You reported that you used a file-based swap back then, > a possible cause of hangups.) I ran into list message content relative to the 256 MiByte swap configuration: QUOTE (2018-Feb-17) The best part is that a Pi2 running 11.0 managed to build world and = kernel=20 using 256 MB of md99 swap. It was using j2, but that's the only = difference.=20 IIRC it took about three days. END QUOTE So the 256M Total might not be not for -j4 but -j2 . > I did not find anything directly on point for your old > RPi2 experiments. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Jan 22 21:53:18 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3C0994FF8D8 for ; Fri, 22 Jan 2021 21:53:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DMtL42kv4z4VJw for ; Fri, 22 Jan 2021 21:53:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611352392; bh=uBmGsV/oLp6ZLSKBqhbRGjX/dgKahI0Vt1B/ciMqDTy=; h=Subject:From:Date:To:From:Subject:Reply-To; b=a5sm8CRJYAU1SLeKWtsfVYwBP68ECd2nfkD/F4lW3UxXqMZs4jWhEqd9a6lS6vsdxSTVh8Nau3ZDszByJi6nOCwtMMNW//HLUrD6Wuapi8QC6bIzwSKvYaBhImmboGLZPQLMmMxlJBXquAW/o5gb/64YtssfqBPJkJki4VkE9l4TXyqJcsAiM4qzlqoH2psvi8NRpidhQlJQgG5Aem8avEGUVZKpKVPZpdfemunPoqoWRgv5uJrQPSvejziDtVojI5jxr3hFOnXrc0xzXWLiMYd4Rb0op8aphsxf7FtwM58RmV0Bce7jMI4raUGyBG3/6HA0rslv0tHRYgm1O35E/Q== X-YMail-OSG: MqxDk48VM1nGa87ss8hWsZEpQS4PJnMUHjm5_EFoMZeUlJLvLfNk6S6M5fx1CU1 l8VIVfrfdNpaIC1a7f8R7ajLbS9eM_3JnJAh2mxmPFfDYbBJCS9aT1b4U41OFRL22JPYb0J7EUSB aToJMuNjNCO0Mt8MHwOfWF7CMRcYS.kpk.32zVt9TBQGBBJzRXr4L4c6uYQpZuKbrgND3T_F__yw VDxBM3RccD3yZZ24XKi.oh.zpVcBMod3LJj77lGlHPmz_FJ9nkAu0bi1VhEKmDngeX_a83sq.itA NnwtzDdoacTTeNl_HwB8x99Sc_YH61aAXFXp5gB9g.VfElVwJrQTyOllPfdgUyQqhN_djUYxNADY J4LuV_hP5bQ6w2WCtyhj6ZEgARTXssT97OlW6jc4LANT.z71IZxGgajBMtxtiz.7rwcbH_gEKd6j PHZRS1TSungce0i687PdJbLCX7R7YsfBq1Nu7mx2tprdFVEtwghJ_tdHhZ_w4dONjZSkAYheRLV3 n7EWFRGe5YgWNuBnEfEFMiGLu7XeJDbBPN9v9eH3vfHCL50carloQ0.JEI5sCxSrffuXl9ZhEnTw l_7FowP8KtqUEhqZ2A3J1yraQNgyVHXaKxwvTL3JWJ98YI3PalUhC9.JMoxurMzn1LmiXt1Q5Vr0 r3MvWfvpuKR_B_awY.6BB8rnmHg1fTlhEt52_Rw.63baHfapHiwWhhhbtjnV7fik4rtT0gW3RwGL sMcgxFprn5EcMtjTqDbNtn0N6jTLvadZrTCxXHqyrlAMHygwnBH_FGaaLrAI8MhAxc_JE1hiHKhm FMaq2cYZbrBrBs6r2P7s.Wv_WS_bmSPvh3WFQr38k67aAV6rWBI6p7ZymEJoG4bi5Q_iInLxfgFM ntjHJlE4pgH3GaPZ7mp.NwF0wfAinCp24tEhTU696f3XUO4_SZgzo0AMD94VYJnDw7KlDw2AMUs7 FD_s9UOWzo0Gp1.etb8CxLTcUnzgflzeeYxP25Ch6yLktB8BPYd8fDu1MWA8AwCbNcSZa0thSrv3 xnl7UCL473NYEtYxowQ9Ntk2LJS4S2KxSDhEtYDw.9w4mVJq4MiBsDl9m_KkBccXNqXHcoPMm_o. 0VQxkgwSP3tQBAv3tJeLGUBOT6QU.RHeqHO.WWlO4UiRMkFnxwTAOS2XyS9CWetY69q.fPPcrC74 .k1.ioQi4PIkcEhmggyTf0Q6EYk8jfTy3o6RgOdk6D6f19zf0VtOfYJ3pX0TKyXFk3OXbf7EHtD5 lqh0Ke89hyxVEO3wCgLdvmlqVXJNxoXJw_3hYA_RdF2ff8o8OD6mA9Bli901YE82q7Yvrbpd9oOJ iJxV3_7t4fMW.VU5Vwdv41gM3O0m6ueI4XU2I2BSvqbil09KW6z3mht.EXoXyrswfY8j0ss1ur5z T.gM_iHmJ.0MDmienAn1mGkxE9H8L8OSY_HC5OrFZrTTjlD1ht5fbqYwgRVoijAMz3vL3Fy1DM_a Dk4xYbEcpJcGhXFfLo0pYJeGvs3aHZe5EfnbuOPIxx9qmV95nvyDhO5s5SFos6TlLD6.1a4OhUJ3 FJtnrHHjxS5v1rxu1lOghDLQkJI4bfUeDxsruV7jtgb2fjRCHc4Wwp6nYrXvX0Js5ESYZ8Q9mxBQ QbY98o.CFy5yEb96PzqDnqYDvNF.iSW0612ve0gi8u5RzY9Sg7I7JKMAyOkTgXXNZLW0JspGemPm UirWXdRE5oHhJba_YTkUL0PQoOVqFataw1ED2HKoMOxb3XHmI.9PtwiugRyNPjEivvhsDMqlnEI0 mIflvqWD9qkw0eWXGPtKvaLl55CTmzmCOyWhl.amOqCKNzY42qodw8ageTQYxDYEqo8bDXQJVnVK 9yMKbfsBU6QnenO0QYcyQfmGFIItSHWO_lwaU8_Wbb4eJbWwzgi0pEr0tp5tFubBkAZIao2J.PRi UpLQYp8kQqw4UTUj.swtqwlCu4i23Vf6SLTiHIWc1AABzURONd5bLhTUvHMr9Sh99j9qBAhkrRqd K0bXj5Jen9yGLU9i_MADePoHxzBsu_sZ_w41VjAiZG6.GuP3KKqQlP6gS9RcZ0IwfwRFCVw.UUua YFHp3kztoUmRM2k_jwLrjgCRwToYY08Gz3IGxpdDX_MnJMZ_SlYazGmX8pwkyXYphJTI_fWwHC8e kLnGkMTm2L40Bes04rqAYC7Tn.HqO9U9YzphlcLh.1K0gOJTKG.k58BWpdVwKH2YRQ_17JiUP9xF 5vgPUFgkOZjAOyItwwD9MJ8h35FmS1kTSIyu1oebRa9hDBuNp6ee57geBctHGCvy5s9nEUgHixTk 2yhbgxnir9GYEadS9Mrhv7ljirx_FDZABj4WDjhNmnfrwo9.9yO93b_6_B.Sj6Y9l4AhXe8Mq.gS 7zU2k67xu9FHzDk190kXTQdNbqbi03EvQLlDjUNbuyHLi5IbbG.WXEOUDikHqTkHuos5lUo4P4Cn FFWaA4_WINyA1BOR9qqyzZUE3qTHjWjo2NRoUov4b9ceifv47AdPuZqg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Jan 2021 21:53:12 +0000 Received: by smtp413.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 51147931c4f55b1944cf090388c4fe2d; Fri, 22 Jan 2021 21:53:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: Date: Fri, 22 Jan 2021 13:53:06 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <36A2E015-78DF-40AB-BF53-FB3D26FA5AAC@yahoo.com> References: <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> <20210121023358.GA58854@www.zefox.net> <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> <20210122011535.GA66611@www.zefox.net> <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DMtL42kv4z4VJw X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.66.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.66.147:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 21:53:18 -0000 I made a discovery of an unfortunate property of META_MODE relative to minimizing builds with installworld invovled between builds as things are. See: https://lists.freebsd.org/pipermail/freebsd-current/2021-January/078488.html for details. I'll note that stable/13 now exists and git's main is now 14-CURRENT. Unfortunately, it seems that main (14-CURRENT) will not get the weekly snapshot builds that are reported at any: https://lists.freebsd.org/pipermail/freebsd-snapshots/202*-*/thread.html and go somewhere below (for example): http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ until sometime after after 13.0-RELEASE : only stable/{11,12,13} likely will, from what I'm told. Also, ci.freebsd.org is not building main (14-CURRENT) yet. stable/13 builds are non-debug builds. https://artifact.ci.freebsd.org/snapshot/ being filling in has not caught up with 13.0-STABLE , stable/13 , 14.0-CURRENT , or main yet. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Jan 22 22:47:00 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A92B44D83CD for ; Fri, 22 Jan 2021 22:47:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DMvX34gMrz4XFP for ; Fri, 22 Jan 2021 22:46:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 10MMkvlq077016 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 22 Jan 2021 14:46:57 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 10MMkuV6077015; Fri, 22 Jan 2021 14:46:56 -0800 (PST) (envelope-from fbsd) Date: Fri, 22 Jan 2021 14:46:56 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Needless work in buildworld Was: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld Message-ID: <20210122224656.GA76907@www.zefox.net> References: <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> <20210121023358.GA58854@www.zefox.net> <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> <20210122011535.GA66611@www.zefox.net> <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> <36A2E015-78DF-40AB-BF53-FB3D26FA5AAC@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36A2E015-78DF-40AB-BF53-FB3D26FA5AAC@yahoo.com> X-Rspamd-Queue-Id: 4DMvX34gMrz4XFP X-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 22:47:00 -0000 On Fri, Jan 22, 2021 at 01:53:06PM -0800, Mark Millard wrote: > > I made a discovery of an unfortunate property of META_MODE relative > to minimizing builds with installworld invovled between builds as > things are. See: > > https://lists.freebsd.org/pipermail/freebsd-current/2021-January/078488.html > > for details. > Is this simply because the "target" is timestamped at installation, while the object files are dated at creation? If so, would some sort of checksum be able to distinguish meaningful changes? Would it be computationally worthwhile? More broadly, I've been surprised to see lots of files associated with foreign architechtures reported in self-hosting buildworld logs on the Pi2/3. Things with mips, ppc and i386 in the pathname. The log always reports building "cross tools" when it's compiling for itself, which puts an odd meaning on the term "cross". Are cross tools and object files for alien hardware really needed in such a case? Thanks for reading! bob prohaska > I'll note that stable/13 now exists and git's main is now 14-CURRENT. > Unfortunately, it seems that main (14-CURRENT) will not get the > weekly snapshot builds that are reported at any: > > https://lists.freebsd.org/pipermail/freebsd-snapshots/202*-*/thread.html > > and go somewhere below (for example): > > http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ > > until sometime after after 13.0-RELEASE : only stable/{11,12,13} > likely will, from what I'm told. Also, ci.freebsd.org is not > building main (14-CURRENT) yet. stable/13 builds are non-debug > builds. > > https://artifact.ci.freebsd.org/snapshot/ being filling in has > not caught up with 13.0-STABLE , stable/13 , 14.0-CURRENT , or > main yet. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > From owner-freebsd-arm@freebsd.org Fri Jan 22 23:24:06 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2E3D84D8FAA for ; Fri, 22 Jan 2021 23:24:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DMwLr71v8z4Yfy for ; Fri, 22 Jan 2021 23:24:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611357842; bh=CkQArQeOUeXmHlLlEcQakZVnbOZ0Re8YbgoIXwQj9wz=; h=Subject:From:Date:To:From:Subject:Reply-To; b=T1RPxGrim6MCCL6QYA7DypNHPWA1793MGz02jJ9jq+LjvZocSlKq5UTJFc30nBWwgtrNqby8OFChnSH/KwID6fo6SfO+oStfJCo9kF91oAyde+N0E9i/cuRvIQ1F1LCyY4anbr/QRzjbC+uv7HHhVS1TqNccnNZbH3ffkuWZrisGZ/NxM3Exo2tdRFIPw+8KVXLl7/q+OnYCQfyGUklgUPxHwe1pbKaUvzh9n/ORMYPRnmV3Conv0cXjdxRJLpGa3yITUswO1h13QLsTu3ma08GexLyQs4AfgDxNxkYNQGdsUeyxXDASYgkFWc1FkpaIW6wE+yLrxAae7ZzwHThdOA== X-YMail-OSG: _dtlqd0VM1lDcgbpXwMO26_wRPOneKdRFdtn9VWorfY5fgZjf7wi2ujPk59YSIN WqgRAZRirz.lTuzcf7N1tmtu1pO3R.Z.13SO6cfkt.spVxkgWRIGsdorVEBsX9l98me8SQzGjoD1 1lUSPfrFx2ttRfzP5IJfl0OEZI9J.VU4nd7zcbWxrYKIryLy7Jgh8u4Ce7kR.3QOPIC0baa2khBB l9RcUyQ32lcQlJv9EIDRaHeJCZEFyvP77GMDolrzKg6iDyHl5n.f2hF2DdiEN8k4sVs60_rI6LNp 3H3qA7coqHDR8VbGzlcE1e5ao8KhwE6vneHQcO6_2gF5pUbUDkoLOmvTwqXu3TKwfaSMkKMQy3X_ Y0ahA9Lkbeu7SNmka6tFY82dCNUKzaLoV7NTylsWmJ0qP1k1jzKRkgC1nDj0_EtwxVabKqv8X.NO RrQcCXHsF3QMP7NfEhIy9wTMQ3Uz66ICmFYMRmLy474Osg1TnTgm3NWCkwjiOw8VQ2nNMZyxRQXU 5cmxHHZeMJ_MrN1bt0BuREKlPy8EnaXeI0A7dIAuN6x_Jxkwv3SH200l16zM_CIThLyIMzjua4VE g7KCqmembb68pNtMPWGzy4EutWOw96VN.hJVi1wSoPJDqq.iLacD7LNDl4ELEdXvD8tcGEvWWcJ5 JYR.zIE9rdnVY8usiQJoOG4tIXRZj4H5YPrZ7VVECUp4qlY04u_mVhsGCWf8Fs1o_bGQZhDc74Qc QT60ZSasQ51ETcmVzgiaRpaL82qpLM3Xt4JDvR158Vbbv3UI2FdTbHA_WL2sd38j7tYix_6aoOPN a7Vugm3Y1s2eIhBPFFj2qcSc_XX_l9uOYMsake7SzrHSqyNyplh0lxvXbhufhAOEohF1D7jYSHNT CsKflxqvqs5e.UrLVujnDoddWl0BHbgnLbAVjqXiuaBNhPJhjc2otTjzTvBbEyduV5PWhumxRRgI VEyQnGw4VttqrsnhVSCFJHiKitOt.WNhRlYNRjlkLO2uu3uTnzvzMWVXjLIdh8nkbZ4eX7v7jA0C GoEW4y5cuGGRr.75Joy545UBTQblnvA._.AFUNHPgJ2x.BbELueYY_giezzkr_7DkAm8T3iXCUht F0kG.JljB5NMST.wWi7OTGjAgryXglJJmcTRGTeCW.xoO4O_0X4m7ofFFnGF5eDiVUh7StRqlS4c fjBwDDbYi.QMwhaNB611aErSVXRfM3sSsprpmod7KIFJif2KGYhSKunmwUb.Yu2ZAHH5tAD0_45Z MRBwJi5ctAt8KvSRBZ7MM6vbP.SW9Pl9MMbRnjd4cefnC9d2AeQd87Qb_yd4jJ6GKFuHF1T.PPO3 snlTcgqeJFGMp2EWXQYxEk.30hrxEaQ9b3LgpEhBIgNDVs6PcfmjT4iGrttHxcM299M8gIjjY4T_ uSaSm7m7ljFRMY8rn9MEtJN9vTyU79H3MwktLwpQHflAQYsfhmh8QxSBreaHGgzddkZp7cqlIYxG N6o.O9TVi7WnEZ.Oro_GTHr9TA4doHLM9inwKYfZbAHIyeFAqKmrSm7cjOFoA1CWn25YGY22HcvY 5v6yKPCaKiZoo9TSvRpQ1dHP.qtjj9I8auf7EbugI9FNp084Btl1kmujpmkd7FC.itfmU42AYUrM YuEwoCmS2n3BZZFXqq0Zmict0nOLs5_RkCgrl7jIdcurNK98hSJESPlVOA6e3ZXVL8hHV_rgTA6K Vp31ZURJ.8fXC0WJGwhyvIyY4XujLf5cq88J0XL0ZoX4VtAnMi.bDUI4G9UBnTWIMxpY1gQXTQy5 dEhzduRelsgOBnisFk3TSg24LVreaxq3q1aRQyWOou1e5Qp1bBhM_KwBCnbHdHs.NZ13kapMPuRq OMIdbKVo6GUN3.Atry5SalJJ7zN.z5aDenXh949t4A99jH0P97mMETvkIAs5lGVfRE5EYnCsspm0 xv0fX1IJGVTnu_fJbPY7qLyeNQePS7e4NjkGsVmlVMKK72Mt5Clad5M2E_n0KKMblJzbzTYqlAui GnNYp3ieIe_9UFa1NX4BV8xtqSBVMp2U2cWynE8iPQjxPKfDAYQmnyJfcbnStFsHFEoTZdJenqk3 3qkyk8B.TeQPM49.Gyk13PyTO_r9lmULaZVObmUoqEw_fTDxfCG75LJ5srlEfjSMbKo5g6GOfCGF x4NnOZaGUEuKNU5FsLF58_B.F6KEwg_tDdd.WLRmGzHf_8bNQh3dMSjlpy8.4oR_5XxC.UmVQCgg HqdECZYWGFZ2QbFOGVT3OBLSOhi__MS7JvWGF_7.P6CrQVfVWJxpCKwxN4XBGhTtSAYrvoQYPksA jQ6zlHwTQVa9TjJ_5b1dcVapDZR48R3jrZEGuC9buucW40zbRDG7gjszW0DuoTTWzB2aGbxTgg_h mNa0vMOCy40NJyuTmhX.wd0eRzL3GvKxuPwS.kJlDFZq8e2qGXfq.cxPJKVtPF0To6s_RVhWQubX kzHHO5jswC_5m64oHmBSkCfba0RwzK.nQztTyXgJ4IACxCVxoFtlBDy7W_.GeU1rr0lsSrOwZwdU 0zeQI7UWPCwi6hutYreISj.Vk0nqTJD_TfIlHmsYCpg3FXRNOdLkZaQmNPjvo9idTLJgBMug6mJJ jpwecoxXBRWJMGsJnFUFS0ccF Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Jan 2021 23:24:02 +0000 Received: by smtp402.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 72a8285c844065bddaa4d7bf67ed8023; Fri, 22 Jan 2021 23:24:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Needless work in buildworld Was: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <20210122224656.GA76907@www.zefox.net> Date: Fri, 22 Jan 2021 15:23:59 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2903491E-7DE7-4F17-B515-120BA447B8B3@yahoo.com> References: <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> <20210121023358.GA58854@www.zefox.net> <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> <20210122011535.GA66611@www.zefox.net> <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> <36A2E015-78DF-40AB-BF53-FB3D26FA5AAC@yahoo.com> <20210122224656.GA76907@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DMwLr71v8z4Yfy X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 23:24:06 -0000 On 2021-Jan-22, at 14:46, bob prohaska wrote: > On Fri, Jan 22, 2021 at 01:53:06PM -0800, Mark Millard wrote: >>=20 >> I made a discovery of an unfortunate property of META_MODE relative >> to minimizing builds with installworld invovled between builds as >> things are. See: >>=20 >> = https://lists.freebsd.org/pipermail/freebsd-current/2021-January/078488.ht= ml >>=20 >> for details. >>=20 > Is this simply because the "target" is timestamped at installation, = while the > object files are dated at creation? If so, would some sort of checksum = be able > to distinguish meaningful changes? Would it be computationally = worthwhile? The files (programs) were used during the activity that generated the = prior build of the target. The worry is that the updated programs might have differing results from older ones and so the new timestamps lead to rebuilding. The worry is just unlikely to be an actual problem for many = of the particular programs. It would be good if META_MODE could ignore those programs that are in = the legacy area and are unlikely to cause the output to vary in some significant way. > More broadly, I've been surprised to see lots of files associated with = foreign > architechtures reported in self-hosting buildworld logs on the Pi2/3. = Things > with mips, ppc and i386 in the pathname. The log always reports = building "cross=20 > tools" when it's compiling for itself, which puts an odd meaning on = the term "cross".=20 > Are cross tools and object files for alien hardware really needed in = such a case? Clang and the llvm tools are by default built to be cross compile capable. You could compile targeting powerpc64 while building on armv7, for example. (Gcc had had separate compilers for such.) In an earlier message I showed my src.conf like file that I use that included turning off generating a clang that can do so, limiting it to arm (including aarch64). This is not the same as the "cross tools" stage issue but does get rid of some of the build activity for clang. It also does not change all llvm tools to completely avoid other processor families. I'll note that building main (14-CURRENT) armv7 from stable/13 armv7 or 13-CURRENT armv7, is an example of "cross tools" being involved. Cross-tools span more issues than you might initially think of, such as some differing defaults for the host targeted files (old context) vs. the new context's files. Thus the: "/usr/src/Makefile.inc1" line 335: SYSTEM_COMPILER: libclang will be = built for bootstrapping a cross-compiler. that is involved. Example difference in context in an explicit notation (amd64 context example, not armv7): -target x86_64-unknown-freebsd13.0 -target x86_64-unknown-freebsd14.0 The processor family is not what is varying for those. >> I'll note that stable/13 now exists and git's main is now 14-CURRENT. >> Unfortunately, it seems that main (14-CURRENT) will not get the >> weekly snapshot builds that are reported at any: >>=20 >> = https://lists.freebsd.org/pipermail/freebsd-snapshots/202*-*/thread.html >>=20 >> and go somewhere below (for example): >>=20 >> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ >>=20 >> until sometime after after 13.0-RELEASE : only stable/{11,12,13} >> likely will, from what I'm told. Also, ci.freebsd.org is not >> building main (14-CURRENT) yet. stable/13 builds are non-debug >> builds. >>=20 >> https://artifact.ci.freebsd.org/snapshot/ being filling in has >> not caught up with 13.0-STABLE , stable/13 , 14.0-CURRENT , or >> main yet. >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jan 23 06:21:05 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 62FC54E75AB for ; Sat, 23 Jan 2021 06:21:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DN5c03V5zz3HXB for ; Sat, 23 Jan 2021 06:21:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611382862; bh=WWkY6KulgbqkTCHXD3oCX3pflb+ZhhI+HY0tiT8m3kO=; h=Subject:From:Date:To:From:Subject:Reply-To; b=eN13ukf2aLYUCYGtUmRxoK5SbMG7No0+Tzfh5G61xWQDpN1qY6SZ7u60MFbpezkwMAgBbh/bdHg6TDvyAhxElHnr8PR4Drlj98edvhpbHwJG6ZM8HeFrzKi3KKdaSD63whFuBX5Zh2lYaLBCOQrdjOxvngiErx+rZMp5ecn3ZLeYY9dVQvBoGF0cMX23n0ylAncVxiJWqKRTefMXh575KR9Zz+6aJN85nrD2HdDIT5ZN73zMG/34HnpfHIZUggaUIoZglFE4jL5leR4nkZF0SgMxEf7Dc/8E/m71Zm0xIRl7TZV8vk/jpV0xz6mllPpiE8UPSt+DU/YM5tMxeK69mA== X-YMail-OSG: zetg3NoVM1k8bf4rfxxotnZG6_LnGzwzTXrp264GexFqA4q2k_NllAW0RIsH6N8 i4bAT.6UFiJMnJQDQaWIhB1us3pMdHulQyfVKqhrLXd.5YwRqPTvyhPihTeLBBZndkMGndnZIf3e _MRjgO3fHHHBIV.ujPcuNJlzTJxm6065r9adXDJtlvvfeywIB5aobWcpbDmpN3vVFtI6T2QuHVVq .viAE1u2oCoEO6RlHqKiMCLCK45972L_Z47rdBgkxGDH1BvZymys.Op7TIgHIZkeXG7o1qu7RTnv m0YdmF7J472u5Q8TZHlwnUC4Q92.4BIGt7xYgl7m7SoPRrLtwd1uZF2.Fqfcb85XL0emD1cDoUok LTmuUjPbnwnBcLpjhCqCIHbq3O.qxE6_dIPM0Glgx8jl5utHbCwRsULKbdFpp6Ji3s_HWBC29l.q tnOSgzxO13XMbOUmFamExIpmOcOEzg81prI5EZDrpfnjAYzY0zEPBIOntpCSzEuH3paW8y__eE_E RiD2UYbb9SH.UJfFe74OyZq0b7WBpeL3DmEjMQ4_D8_rEOiTEmfHZteUuXEcXyScF3SKWyOpPT5n mv4JRTGGpZju3zW5VY83O06A_vaa1WVaKpQGHbfDpAzesHHygIs6WWoSZU0PA60cFIy9GhL1A8s0 bFVOEJExLcB98lsiBHRRj0kn.FP6._nIoVxcbwvpidyAriFxgw8GIt32UMPzWc6.H.JbgoQakrc1 r9KeNeRvKBaG3Yif2CzS7cM_dcDSm.lm2pQIG06LOEuVwy3Oynj8HLEqYL5M5NcSHDiKvPkvlrO5 YoqWvtepfH8ibeKsZZior1P4QgyXqrCHI0WrOFW3P_jbWk6gTxAGRuDW7T13ldXJs8.uPTn7uxJ8 rKZDyxKfSZJTn.5tdUze6M7V5GPr.wT2WjZH7XgyIt3O9NyhOTpCKRra04LQnAhZpJ_EZWP2Bx5j do_M8mKaHYaDtx8hbzg6e5UOiLhKtFaWjdLiivES1oTbk_qiPYhnUbtWgYwG.5TmjxJ34jdo46bg WFtZm1LlOUXkfXlxWAnqhh9.biQmw_YDW4J2UG9Y4NLpH60WeQ9sa75qrRhUHsD6_DxqFIU02nKL mKWwHQvgRBHmxHNS9WFS0ABCwnhL.XNMkv_hkZGdBlQFx84VqqNOEudMdPVpx2Wno1YipeeErkM4 Thh4cob8AEU5lCGubw.wsi9fV7LtawqfWtmm6JXSYZOWr8xJxeDhlT9tn8wITLoAIxvcblIiPn.k NGm5OaHb02R3pw21ok1Dom.1Y4KOT3hP3biwWf1hyQcVt19CoDW4u.KehE0AJKyTNnASliWNVV0c iH0ICQ5HI08YNaRkjYmVUtMe025ubX.zsGwWLe8IAzjThmHNMWL4i97ccZ1t5nkA4yuBBWKKAd8o sGmqGUW.3Zc_rDMko3wS5Gi1p1MtqjMqq0aECkX5zQJEVQNJ1sj_b18GmfW3sNINj.awAm60dVF2 hRsDnR5IIAcRvxPKW1uKt1IYYQfIZnBJWeNvgBaGcyOgdll8RCCdEspQNztNJyrR8RFNyRCYKnvr zD5znQZF0zMojb3D3fNc4pMpKzXIB.v_6YNvGD_kEuBzUS7VbHmaS3N..Qo.mdhzcwkotam0HoSg tls899R.LFDVn3o7oSbVr1E84m5h63kRXbXq47S8arzKf4YnBdp0PZsFR1oGCJzAWL6BoT2rP0Sm SFezsPyKc7QAqJlb3JRUan_Ljcq_IJ6MEYMNSyrQHQ2s8llu5OW3x8J38O92w2xmF_DShrATU57y RBF3OpYuRn_Ewdc2yR7Oq5dYdybt9FhQEekmqBnqpJoAmidKTt3lTeYaOXgNehMJgEXwSzd69eI6 Ph7nBFIaf1OwMXDe1qAgcowSjUXAKtrUeEBjL6IJrha2n86dfNd.WL1WGWQvVBecRzECFqQQsV9R gYe8_G9U3CSNo7jrfyvVzHUEnzFfAtwVK.CKUe21yH3sgPc5DW6k1k_VloUxHsgwaf77vWpJspNe YDxNK55k2ax25AZNxisi8ODXLFirEgLQZ_tYE2tVlixHDAIyFx3nkRw2NuGvcY_.3kfypk8CAxia LiZ8FPiXQipNXDUZXjtf7AWatFlDxkJDCmfol3kqlmIGYbjI3uhNgqaTFnZb5NdpvSj1qIv8gluW eG9wrYgcMJ9Scz79fExy1wtHOo874KYcAs2s2uRV6RCCqU17E9kT_7KvlXg.b.zEbVLLtwJRrEAy Lu_gOl6dFT09BPwdQk7HfLPrRWY.NcXC3VatLVQRXhCMK.Od05kpsGLvLr5JOgTHef802Nmroqj9 YRrNHEIReIKASQQeh25lYuzoILPfE8b.nNzIs7xyteJrHLLfqmRbqASvkldILNbMLhTrrClBTGW7 9jjV7x5SBVUQWBFTL0RDEQerJtbRnr5WMpSSb3w..FRKZS986dzENXqaHgnGGwOC9hWw4JQtGlFX LeJr_Y4wW16ZxHLPLYR9WsuTuCq5RZq0fGUdI4TvADNcFqUTFpOJCzHSRhgt8VMYADNAjHqHWYp7 x9Jd__yXWgxzJWMExAMx6ouFmVMoA16AYYTRha_s3gam3pw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Jan 2021 06:21:02 +0000 Received: by smtp425.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 61481be51602cc494e60ca898124d0d3; Sat, 23 Jan 2021 06:20:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Needless work in buildworld Was: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <2903491E-7DE7-4F17-B515-120BA447B8B3@yahoo.com> Date: Fri, 22 Jan 2021 22:20:53 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> <20210121023358.GA58854@www.zefox.net> <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> <20210122011535.GA66611@www.zefox.net> <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> <36A2E015-78DF-40AB-BF53-FB3D26FA5AAC@yahoo.com> <20210122224656.GA76907@www.zefox.net> <2903491E-7DE7-4F17-B515-120BA447B8B3@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DN5c03V5zz3HXB X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.84:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2021 06:21:05 -0000 On 2021-Jan-22, at 15:23, Mark Millard wrote: > On 2021-Jan-22, at 14:46, bob prohaska wrote: >=20 >> On Fri, Jan 22, 2021 at 01:53:06PM -0800, Mark Millard wrote: >>>=20 >>> I made a discovery of an unfortunate property of META_MODE relative >>> to minimizing builds with installworld invovled between builds as >>> things are. See: >>>=20 >>> = https://lists.freebsd.org/pipermail/freebsd-current/2021-January/078488.ht= ml >>>=20 >>> for details. >>>=20 >> Is this simply because the "target" is timestamped at installation, = while the >> object files are dated at creation? Just FYI, In things such as (abbreviated): file '. . ./tmp/legacy/usr/sbin/awk' is newer than the target... The "target" is the object file or whatever that might need to be replaced, not the . . ./tmp/legacy/usr/sbin/???. The examples of such lines listed the target file path before the word "file" above. I only showed one line with the common suffix text, no hint of the prior text on the lines summarized. So the targets were timestamped at the prior build's creation of them. It is the installworld installkernel sorts of activity that ends up with . . ./tmp/legacy/usr/sbin/awk and the like having time stamps from the new build's time frame. But the META_MODE records indicate that . . ./tmp/legacy/usr/sbin/awk (or whatever) was involved in generating the target in the prior build so the updated timestamp leads to questions of needing regeneration of the target. But a . . ./tmp/legacy/. . ./??? generally is not likely to cause such a need, even with new timestamps. >> If so, would some sort of checksum be able >> to distinguish meaningful changes? Would it be computationally = worthwhile? I leave the overall issue to Bryan Drewery to decide if there is something to be done or not. > The files (programs) were used during the activity that generated the = prior > build of the target. The worry is that the updated programs might have > differing results from older ones and so the new timestamps lead to > rebuilding. The worry is just unlikely to be an actual problem for = many of > the particular programs. >=20 > It would be good if META_MODE could ignore those programs that are in = the > legacy area and are unlikely to cause the output to vary in some > significant way. >=20 >> More broadly, I've been surprised to see lots of files associated = with foreign >> architechtures reported in self-hosting buildworld logs on the Pi2/3. = Things >> with mips, ppc and i386 in the pathname. The log always reports = building "cross=20 >> tools" when it's compiling for itself, which puts an odd meaning on = the term "cross".=20 >> Are cross tools and object files for alien hardware really needed in = such a case? >=20 > Clang and the llvm tools are by default built to be cross > compile capable. You could compile targeting powerpc64 while > building on armv7, for example. (Gcc had had separate > compilers for such.) >=20 > In an earlier message I showed my src.conf like file that I > use that included turning off generating a clang that can > do so, limiting it to arm (including aarch64). This is > not the same as the "cross tools" stage issue but does get > rid of some of the build activity for clang. It also does > not change all llvm tools to completely avoid other processor > families. >=20 > I'll note that building main (14-CURRENT) armv7 from > stable/13 armv7 or 13-CURRENT armv7, is an example of > "cross tools" being involved. Cross-tools span more > issues than you might initially think of, such as some > differing defaults for the host targeted files (old > context) vs. the new context's files. Thus the: >=20 > "/usr/src/Makefile.inc1" line 335: SYSTEM_COMPILER: libclang will be = built for bootstrapping a cross-compiler. >=20 > that is involved. Example difference in context in an > explicit notation (amd64 context example, not armv7): >=20 > -target x86_64-unknown-freebsd13.0 > -target x86_64-unknown-freebsd14.0 >=20 > The processor family is not what is varying for those. >=20 >>> I'll note that stable/13 now exists and git's main is now = 14-CURRENT. >>> Unfortunately, it seems that main (14-CURRENT) will not get the >>> weekly snapshot builds that are reported at any: >>>=20 >>> = https://lists.freebsd.org/pipermail/freebsd-snapshots/202*-*/thread.html >>>=20 >>> and go somewhere below (for example): >>>=20 >>> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ >>>=20 >>> until sometime after after 13.0-RELEASE : only stable/{11,12,13} >>> likely will, from what I'm told. Also, ci.freebsd.org is not >>> building main (14-CURRENT) yet. stable/13 builds are non-debug >>> builds. >>>=20 >>> https://artifact.ci.freebsd.org/snapshot/ being filling in has >>> not caught up with 13.0-STABLE , stable/13 , 14.0-CURRENT , or >>> main yet. >>>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jan 23 17:37:52 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 876D54D949B for ; Sat, 23 Jan 2021 17:37:52 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DNNcv4NVpz4kLk for ; Sat, 23 Jan 2021 17:37:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 10NHbsHC084035 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 23 Jan 2021 09:37:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 10NHbsF2084034; Sat, 23 Jan 2021 09:37:54 -0800 (PST) (envelope-from fbsd) Date: Sat, 23 Jan 2021 09:37:54 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Needless work in buildworld Message-ID: <20210123173754.GA83834@www.zefox.net> References: <20210121023358.GA58854@www.zefox.net> <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> <20210122011535.GA66611@www.zefox.net> <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> <36A2E015-78DF-40AB-BF53-FB3D26FA5AAC@yahoo.com> <20210122224656.GA76907@www.zefox.net> <2903491E-7DE7-4F17-B515-120BA447B8B3@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DNNcv4NVpz4kLk X-Spamd-Bar: / X-Spamd-Result: default: False [0.90 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2021 17:37:52 -0000 On Fri, Jan 22, 2021 at 10:20:53PM -0800, Mark Millard wrote: > > In things such as (abbreviated): > > file '. . ./tmp/legacy/usr/sbin/awk' is newer than the target... > > The "target" is the object file or whatever that might need to > be replaced, not the . . ./tmp/legacy/usr/sbin/???. The > examples of such lines listed the target file path before > the word "file" above. > > I only showed one line with the common suffix text, no hint of > the prior text on the lines summarized. > > So the targets were timestamped at the prior build's creation > of them. > > It is the installworld installkernel sorts of activity that ends > up with . . ./tmp/legacy/usr/sbin/awk and the like having time > stamps from the new build's time frame. But the META_MODE > records indicate that . . ./tmp/legacy/usr/sbin/awk (or whatever) > was involved in generating the target in the prior build so the > updated timestamp leads to questions of needing regeneration of > the target. But a . . ./tmp/legacy/. . ./??? generally is not > likely to cause such a need, even with new timestamps. > > > >> If so, would some sort of checksum be able > >> to distinguish meaningful changes? Would it be computationally worthwhile? > > I leave the overall issue to Bryan Drewery to decide if there is > something to be done or not. > My thinking regarding checksums was absolutely wrong; I wanted to compare files that hadn't been created..... In deciding whether to recompile, say, /usr/bin/awk, one must compare the creation date of the installed /usr/bin/awk to every file it depends on. If any of those files is newer, the whole chain must be recompiled. I can readily see how this would avalanche, but it seems necessary. Have I got at least that part right? > > The files (programs) were used during the activity that generated the prior > > build of the target. The worry is that the updated programs might have > > differing results from older ones and so the new timestamps lead to > > rebuilding. The worry is just unlikely to be an actual problem for many of > > the particular programs. > > > > It would be good if META_MODE could ignore those programs that are in the > > legacy area and are unlikely to cause the output to vary in some > > significant way. > > Is this to say that META_MODE is checking outside the dependency chain (web?), reacting to files changed but not to be used again? > >> More broadly, I've been surprised to see lots of files associated with foreign > >> architechtures reported in self-hosting buildworld logs on the Pi2/3. Things > >> with mips, ppc and i386 in the pathname. The log always reports building "cross > >> tools" when it's compiling for itself, which puts an odd meaning on the term "cross". > >> Are cross tools and object files for alien hardware really needed in such a case? > > > > Clang and the llvm tools are by default built to be cross > > compile capable. You could compile targeting powerpc64 while > > building on armv7, for example. (Gcc had had separate > > compilers for such.) > > > > In an earlier message I showed my src.conf like file that I > > use that included turning off generating a clang that can > > do so, limiting it to arm (including aarch64). This is > > not the same as the "cross tools" stage issue but does get > > rid of some of the build activity for clang. It also does > > not change all llvm tools to completely avoid other processor > > families. > > Probably wisest if I leave artifice like that alone. Best to minimize the amount of tampering at the expense of wasting cpu cycles. The build systems is already immensely complicated and private variations just make it worse. > > I'll note that building main (14-CURRENT) armv7 from > > stable/13 armv7 or 13-CURRENT armv7, is an example of > > "cross tools" being involved. Cross-tools span more > > issues than you might initially think of, such as some > > differing defaults for the host targeted files (old > > context) vs. the new context's files. Thus the: > > > > "/usr/src/Makefile.inc1" line 335: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. > > > > that is involved. Example difference in context in an > > explicit notation (amd64 context example, not armv7): > > > > -target x86_64-unknown-freebsd13.0 > > -target x86_64-unknown-freebsd14.0 > > > > The processor family is not what is varying for those. > > That puts a new light on the notion of "cross". > >>> I'll note that stable/13 now exists and git's main is now 14-CURRENT. > >>> Unfortunately, it seems that main (14-CURRENT) will not get the > >>> weekly snapshot builds that are reported at any: > >>> > >>> https://lists.freebsd.org/pipermail/freebsd-snapshots/202*-*/thread.html > >>> > >>> and go somewhere below (for example): > >>> > >>> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ > >>> > >>> until sometime after after 13.0-RELEASE : only stable/{11,12,13} > >>> likely will, from what I'm told. Also, ci.freebsd.org is not > >>> building main (14-CURRENT) yet. stable/13 builds are non-debug > >>> builds. > >>> > >>> https://artifact.ci.freebsd.org/snapshot/ being filling in has > >>> not caught up with 13.0-STABLE , stable/13 , 14.0-CURRENT , or > >>> main yet. > >>> With my thanks, bob prohaska