From nobody Fri Sep 10 15:27:07 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 62F0E17A95EC for ; Fri, 10 Sep 2021 15:27:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H5fqv1r77z4pVr for ; Fri, 10 Sep 2021 15:27:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 204BC73AB for ; Fri, 10 Sep 2021 15:27:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 18AFR7i2083569 for ; Fri, 10 Sep 2021 15:27:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 18AFR72f083568 for freebsd-arm@FreeBSD.org; Fri, 10 Sep 2021 15:27:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 258405] rpib4 : display resolution 4k mode and network interface does not properly work together Date: Fri, 10 Sep 2021 15:27:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: x11max1@unitybox.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258405 Bug ID: 258405 Summary: rpib4 : display resolution 4k mode and network interface does not properly work together Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: x11max1@unitybox.de Created attachment 227806 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D227806&action= =3Dedit network interface genet0 and display resolution 1920x1280 only I own several rpib4 model b and one of them i use as a desktop pc connected= to a 4k monitor. Installed is FreeBSD version 13.0. FreeBSD rpi4b 13.0-CURRENT FreeBSD 13.0-CURRENT #14 r370524: Thu Sep 9 08:46:11 CEST 2021 root@rpi4b:/usr/obj/usr/src/arm64.aarch64/sys/GENERI= C=20 arm64 There are some problem with the network interface and display relosolution. If rpib4 is configured to load a display resolution in 4K mode (3840x2160) = the network interface is not coming up, means the network interface named "gene= t0" is no more in the device tree and could not be loaded. But without 4k mode the network interface is coming up. With this configura= tion the max display resolution is "1920x1280" i can use with rpib4.=20 Somewhere else have observe this behaviour ? If starting up the same rpib4 using raspberry OS all is fine. The problem seems to be located in the file: bcm2711-rpi-4-b.dtb=20 T=C5=9Ataarting in 4k mode the network interface "genet0" is configured out= after boot process is done. Don't know see why. /usr/local/share/rpi-firmware comes with /usr/local/share/rpi-firmware. -rw-r--r-- 1 root wheel 49090 Mar 3 2021 bcm2711-rpi-4-b.dtb stefanev@rpi4b> file -s bcm2711-rpi-4-b.dtb bcm2711-rpi-4-b.dtb_ORIG: Device Tree Blob version 17, size=3D49090, boot C= PU=3D0, string block size=3D4026, DT structure block size=3D44992 But i have replaced this file with an older one, that makes it possible to = root up rpib4. /boot/msdos/ -rwxr-xr-x 1 root wheel 40659 Mar 13 13:59 bcm2711-rpi-4-b.dtb stefanev@rpi4b> file -s bcm2711-rpi-4-b.dtb=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 /boot/msdos bcm2711-rpi-4-b.dtb: Device Tree Blob version 17, size=3D40659, boot CPU=3D= 0, string block size=3D3643, DT structure block size=3D36944 stefanev@rpi4b> cat config.txt=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 /boot/msdos [all] arm_64bit=3D1 # enable audio (loads snd_bmc2835) #dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don,sd_poll_once=3Don dtparam=3Di2c_arm=3Don dtoverlay=3Denc28j60 dtoverlay=3Dmmc dtoverlay=3Ddisable-bt device_tree_address=3D0x4000 kernel=3Du-boot.bin #=20 dtoverlay=3Dhifiberry-dac dtoverlay=3Dhifiberry-dacplus dtoverlay=3Dhifiberry-digi dtoverlay=3Dhifiberry-amp dtoverlay=3Diqaudio-dac dtoverlay=3Diqaudio-dacplus dtdebug=3D1 [pi4] #hdmi_safe=3D1 ##### START audio over hdmi ##### # You need them both set because hdmi_group=3D1 tells the kernel we are usi= ng CEA=20 # mode (for TV's, has sound) instead of DMT mode(for monitors, no sound) an= d=20 # hdmi_drive=3D2 tells the kernel to use HDMI if available. (HDMI mode has = sound, DVI does not.) #hdmi_group=3D2 hdmi_group=3D1 hdmi_drive=3D2 ##### END audio over hdmi ##### armstub=3Darmstub8-gic.bin #### with this setting rpib4 won't start up, boot process stucks if loading= 4k #dtoverlay=3Dvc4-fkms-v3d.dtbo #dtoverlay=3Dvc4-kms-v3d-pi4.dtbo #hdmi_enable_4kp60=3D1 #hdmi_mode=3D76 #hdmi_cvt 3840 2160 60 #max_framebuffer_width=3D3840 #max_framebuffer=3Dheight=3D2160 #hdmi_ignore_edid=3D0xa5000080 max_framebuffers=3D2 disable_overscan=3D1 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Sep 11 19:34:40 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3E39317A890C for ; Sat, 11 Sep 2021 19:34:50 +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 4H6NHF174sz4g0D for ; Sat, 11 Sep 2021 19:34:48 +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 18BJYeWl066045 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 11 Sep 2021 12:34:41 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 18BJYe8Q066044; Sat, 11 Sep 2021 12:34:40 -0700 (PDT) (envelope-from fbsd) Date: Sat, 11 Sep 2021 12:34:40 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Python2.7 seemingly stuck on RPI3 Message-ID: <20210911193440.GA65782@www.zefox.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4H6NHF174sz4g0D 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 [0.88 / 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)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.98)[0.978]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; 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]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N A present attempt to compile www/chromium on a Pi3 using a single make job has gotten stuck in a curious way: Python2.7 appears to be stuck, or nearly stuck, reading swap. The machine isn't out of swap, in fact swap isn't even very busy, around 85% for the hard disk partition and 15% for the microSD partition. Queue lengths are small and kBps close to 1000 for both. Here's a sample of disk activity: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr mm0 da0 in sy cs us sy id 0 0 13 2560404 57968 2546 103 83 35 2505 6020 0 0 20952 862 6525 19 4 78 dT: 10.009s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 0 147 147 944 0.9 0 0 0.0 0 0 0.0 13.6 mmcsd0 0 147 147 944 0.9 0 0 0.0 0 0 0.0 13.8 mmcsd0s2 1 144 141 878 6.6 2 76 31.8 0 0 0.0 85.9 da0 0 147 147 944 0.9 0 0 0.0 0 0 0.0 13.8 mmcsd0s2b 1 143 141 878 6.6 2 76 31.8 0 0 0.0 86.0 da0s2 0 2 0 0 0.0 2 76 31.8 0 0 0.0 0.6 da0s2a 1 141 141 878 6.6 0 0 0.0 0 0 0.0 86.0 da0s2b Sat Sep 11 12:01:49 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 882800 960400 48% /dev/mmcsd0s2b 1843200 880600 962600 48% Total 3686400 1763400 1923000 48% Here's a sample of top output last pid: 41683; load averages: 0.04, 0.13, 0.15 up 15+17:47:00 12:02:29 48 processes: 1 running, 47 sleeping CPU: 0.1% user, 0.0% nice, 0.7% system, 0.7% interrupt, 98.5% idle Mem: 429M Active, 23M Inact, 182M Laundry, 222M Wired, 87M Buf, 44M Free Swap: 3600M Total, 1711M Used, 1889M Free, 47% Inuse, 3784K In PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 24726 root 1 20 0 1566M 627M swread 1 7:36 1.83% python2.7 1074 bob 1 20 0 14M 1100K CPU0 0 39:03 0.14% top 881 root 1 20 0 12M 268K select 0 6:49 0.02% powerd 1069 bob 1 20 0 20M 684K select 0 3:28 0.02% sshd 942 root 1 20 0 20M 644K select 3 3:18 0.00% sshd 24504 root 1 41 0 370M 356K select 2 1:17 0.00% ninja 945 root 1 20 0 17M 972K select 2 1:04 0.00% sendmail 827 root 1 20 0 13M 616K select 2 1:03 0.00% syslogd Admittedly, 1700M of swap is a lot in use, but in the past the machine was able to work through much higher swap usage. Now it seems well and truly stuck, though still reasonably responisve to keyboard input. It's unclear to me if this is my error or something else. Thanks for reading, any thoughts appreciated. bob prohaska From nobody Sat Sep 11 22:19:23 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D11A417C20C6 for ; Sat, 11 Sep 2021 22:19:33 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H6RxJ3Lqkz3qkg for ; Sat, 11 Sep 2021 22:19:32 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.16.1/8.16.1) with ESMTPS id 18BMJO6C037619 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 12 Sep 2021 00:19:24 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.16.1/8.16.1/Submit) id 18BMJN0S037618 for freebsd-arm@freebsd.org; Sun, 12 Sep 2021 00:19:23 +0200 (CEST) (envelope-from fuz) Date: Sun, 12 Sep 2021 00:19:23 +0200 From: Robert Clausecker To: Mark Millard via freebsd-arm Subject: Re: armv7 (on aarch64) 13 GByte+ poudriere build logs (and growing) for devel/cargo-c and for devel/rust-cbindgen (build stage over 15 Hr each so far) Message-ID: References: <67875293-A964-4471-A7A8-D027243A4629.ref@yahoo.com> <67875293-A964-4471-A7A8-D027243A4629@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67875293-A964-4471-A7A8-D027243A4629@yahoo.com> X-Rspamd-Queue-Id: 4H6RxJ3Lqkz3qkg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su X-Spamd-Result: default: False [-3.28 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[fuz.su]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.992]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Mark, I've already reported this issue in PR #257419. Yours, Robert Clausecker Am Sat, Sep 11, 2021 at 03:17:08PM -0700 schrieb Mark Millard via freebsd-arm: > The following is from an on-going attempt at a poudreire bulk -a build targeting > armv7 on an aarch64 system (Cortext-A72's). > > >From ps -auxd : > > root 32585 0.0 0.0 15540 6708 1 I 23:16 0:00.20 | |-- sh: poudriere[main-CA7-default][15]: build_pkg (cargo-c-0.9.2_1) (sh) > root 58437 0.0 0.0 15540 6700 1 I 23:22 0:00.00 | | `-- sh: poudriere[main-CA7-default][15]: build_pkg (cargo-c-0.9.2_1) (sh) > root 58440 0.0 0.0 6760 4232 1 IJ 23:22 0:00.15 | | `-- /usr/bin/make -C /usr/ports/devel/cargo-c build > root 58459 41.3 0.1 203760 80560 1 SJ 23:22 342:31.37 | | `-- /usr/local/bin/cargo build --manifest-path /wrkdirs/usr/ports/devel/cargo-c/work/cargo-c-0.9.2+cargo-0.55/C > root 61396 0.0 3.0 2078828 1995664 1 IJ 23:23 33:21.39 | | `-- /usr/local/bin/rustc --crate-name im_rc --edition=2018 /wrkdirs/usr/ports/devel/cargo-c/work/cargo-c-0.9. > > # ls -Tld /usr/local/poudriere/data/logs/bulk/main-CA7-default/2021-09-10_17h13m49s/logs/cargo-c-0.9.2_1.log > -rw-r--r-- 3 root wheel 13355735461 Sep 11 14:35:46 2021 /usr/local/poudriere/data/logs/bulk/main-CA7-default/2021-09-10_17h13m49s/logs/cargo-c-0.9.2_1.log > > thread 'rustc' panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:560:5 > stack backtrace: > note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. > > error: internal compiler error: unexpected panic > > note: the compiler unexpectedly panicked. this is a bug. > > note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md > > note: rustc 1.54.0 running on armv7-unknown-freebsd > > note: compiler flags: -C opt-level=2 -C embed-bitcode=no -C target-cpu=cortex-a7 -C linker=cc -C link-arg=-fstack-protector-strong --crate-type lib > > note: some of the compiler flags provided by cargo are hidden > > query stack during panic: > #0 [trimmed_def_paths] calculating trimmed def paths > #1 [lint_mod] linting module `vector` > #2 [analysis] running analysis passes on this crate > end of query stack > thread 'rustc' panicked at 'cannot panic during the backtrace function', library/std/src/../../backtrace/src/lib.rs:147:13 > stack backtrace: > 0: 0x4704a088 - ::fmt::h62ff206af4f307a3 > 1: 0x47113174 - core::fmt::write::h1cff52b8c9dac53e > 2: 0x47039e34 - > > . . . > > 54: 0x41ec94e4 - > 55: 0x4703fbd0 - > 56: 0x401361bc - > 57: 0x40135cd8 - pthread_create > 58: 0x40138b64 - pthread_peekjoin_np > 59: 0x40138b64 - pthread_peekjoin_np > 60: 0x40138b64 - pthread_peekjoin_np > 61: 0x40138b64 - pthread_peekjoin_np > . . . > 305514048: 0x40138b64 - pthread_peekjoin_np > 305514049: 0x40138b64 - pthread_peekjoin_np > 305514050: 0x40138b64 - pthread_peekjoin_np > 305514051: 0x40138b64 - pthread_peekjoin_np > 305514052: 0x40138b64 - pthread_peekjoin_np > 305514053: 0x40138b64 - pthread_peekjoin_np > 305514054: 0x40138b64 - pthread_peekjoin_np > 305514055: 0x40138b64 - pthread_peekjoin_np > . . . > > > root 84847 0.0 0.0 15540 6704 1 I 23:09 0:00.14 | |-- sh: poudriere[main-CA7-default][16]: build_pkg (rust-cbindgen-0.20.0_1) (sh) > root 680 0.0 0.0 15540 6696 1 I 23:11 0:00.00 | | `-- sh: poudriere[main-CA7-default][16]: build_pkg (rust-cbindgen-0.20.0_1) (sh) > root 683 0.0 0.0 6120 3512 1 IJ 23:11 0:00.08 | | `-- /usr/bin/make -C /usr/ports/devel/rust-cbindgen build > root 709 80.8 0.1 116812 54448 1 RJ 23:11 362:50.69 | | `-- /usr/local/bin/cargo build --manifest-path /wrkdirs/usr/ports/devel/rust-cbindgen/work/cbindgen-0.20.0/Car > root 1882 12.9 3.0 2045144 1970100 1 IJ 23:11 35:48.21 | | `-- /usr/local/bin/rustc --crate-name tempfile --edition=2018 /wrkdirs/usr/ports/devel/rust-cbindgen/work/cb > > # ls -TldtL /usr/local/poudriere/data/logs/bulk/main-CA7-default/2021-09-10_17h13m49s/logs/rust-cbindgen-0.20.0_1.log > -rw-r--r-- 3 root wheel 13910063729 Sep 11 14:36:43 2021 /usr/local/poudriere/data/logs/bulk/main-CA7-default/2021-09-10_17h13m49s/logs/rust-cbindgen-0.20.0_1.log > > thread 'rustc' panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:560:5 > stack backtrace: > note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. > > error: internal compiler error: unexpected panic > > note: the compiler unexpectedly panicked. this is a bug. > > note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md > > note: rustc 1.54.0 running on armv7-unknown-freebsd > > note: compiler flags: -C opt-level=2 -C embed-bitcode=no -C target-cpu=cortex-a7 -C linker=cc -C link-arg=-fstack-protector-strong --crate-type lib > > note: some of the compiler flags provided by cargo are hidden > > query stack during panic: > #0 [trimmed_def_paths] calculating trimmed def paths > #1 [lint_mod] linting module `file` > #2 [analysis] running analysis passes on this crate > end of query stack > thread 'rustc' panicked at 'cannot panic during the backtrace function', library/std/src/../../backtrace/src/lib.rs:147:13 > stack backtrace: > 0: 0x4704a088 - ::fmt::h62ff206af4f307a3 > 1: 0x47113174 - core::fmt::write::h1cff52b8c9dac53e > 2: 0x47039e34 - > 3: 0x470443fc - > . . . > 51: 0x4703fbd0 - > 52: 0x401361bc - > 53: 0x40135cd8 - pthread_create > 54: 0x40138b64 - pthread_peekjoin_np > 55: 0x40138b64 - pthread_peekjoin_np > 56: 0x40138b64 - pthread_peekjoin_np > 57: 0x40138b64 - pthread_peekjoin_np > 58: 0x40138b64 - pthread_peekjoin_np > . . . > 320127389: 0x40138b64 - pthread_peekjoin_np > 320127390: 0x40138b64 - pthread_peekjoin_np > 320127391: 0x40138b64 - pthread_peekjoin_np > 320127392: 0x40138b64 - pthread_peekjoin_np > 320127393: 0x40138b64 - pthread_peekjoin_np > 320127394: 0x40138b64 - pthread_peekjoin_np > 320127395: 0x40138b64 - pthread_peekjoin_np > . . . > > For reference: > > I have higer timeout figures set for poudriere than the > defaults. > > I have since forced the two builders to stop by killing > processes. > > I will be deleteing the log files because of their size. > > The system is a HoneyComb (16 core Cortext-A72). > > # uname -apKU > FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 > > # poudriere jail -i -jmain-CA7 > Jail name: main-CA7 > Jail version: 14.0-CURRENT > Jail arch: arm.armv7 > Jail method: null > Jail mount: /usr/obj/DESTDIRs/main-CA7-poud > Jail fs: > Jail updated: 2021-06-27 17:58:33 > Jail pkgbase: disabled > > # cd /usr/ports/ > # ~/fbsd-based-on-what-commit.sh > branch: main > merge-base: b0c4eaac2a3aa9bc422c21b9d398e4dbfea18736 > merge-base: CommitDate: 2021-09-07 21:55:24 +0000 > b0c4eaac2a3a (HEAD -> main, freebsd/main, freebsd/HEAD) security/suricata: Add patch for upstream locking fix > n557269 (--first-parent --count for merge-base) > > There are other ports that fail to build in various ways, > but so far these two have the only system-wide nasty > consequences for their failure mode. > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > > -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From nobody Sat Sep 11 23:43:55 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A412D17C6173 for ; Sat, 11 Sep 2021 23:43:57 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H6Tph5M7wz4hvd for ; Sat, 11 Sep 2021 23:43:56 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.16.1/8.16.1) with ESMTPS id 18BNhtOV042556 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 12 Sep 2021 01:43:55 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.16.1/8.16.1/Submit) id 18BNhtV0042555 for freebsd-arm@freebsd.org; Sun, 12 Sep 2021 01:43:55 +0200 (CEST) (envelope-from fuz) Date: Sun, 12 Sep 2021 01:43:55 +0200 From: Robert Clausecker To: Mark Millard via freebsd-arm Subject: Re: armv7 (on aarch64) 13 GByte+ poudriere build logs (and growing) for devel/cargo-c and for devel/rust-cbindgen (build stage over 15 Hr each so far) Message-ID: References: <67875293-A964-4471-A7A8-D027243A4629@yahoo.com> <5CFAC3D9-FE4A-4A0B-8897-ECF12EB2FF05@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5CFAC3D9-FE4A-4A0B-8897-ECF12EB2FF05@yahoo.com> X-Rspamd-Queue-Id: 4H6Tph5M7wz4hvd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[fuz.su]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Mark, Please read the relevant PR. I have enumerated all ports that fail with this kind of error by painstakingly compiling them all and watching the logs for unexpected growth. No need to do it again. Yours, Robert Clausecker Am Sat, Sep 11, 2021 at 04:32:42PM -0700 schrieb Mark Millard via freebsd-arm: > On 2021-Sep-11, at 15:48, Mark Millard wrote: > > > > On 2021-Sep-11, at 15:17, Mark Millard wrote: > > > >> The following is from an on-going attempt at a poudreire bulk -a build targeting > >> armv7 on an aarch64 system (Cortext-A72's). > >> > >> From ps -auxd : > >> > >> root 32585 0.0 0.0 15540 6708 1 I 23:16 0:00.20 | |-- sh: poudriere[main-CA7-default][15]: build_pkg (cargo-c-0.9.2_1) (sh) > >> root 58437 0.0 0.0 15540 6700 1 I 23:22 0:00.00 | | `-- sh: poudriere[main-CA7-default][15]: build_pkg (cargo-c-0.9.2_1) (sh) > >> root 58440 0.0 0.0 6760 4232 1 IJ 23:22 0:00.15 | | `-- /usr/bin/make -C /usr/ports/devel/cargo-c build > >> root 58459 41.3 0.1 203760 80560 1 SJ 23:22 342:31.37 | | `-- /usr/local/bin/cargo build --manifest-path /wrkdirs/usr/ports/devel/cargo-c/work/cargo-c-0.9.2+cargo-0.55/C > >> root 61396 0.0 3.0 2078828 1995664 1 IJ 23:23 33:21.39 | | `-- /usr/local/bin/rustc --crate-name im_rc --edition=2018 /wrkdirs/usr/ports/devel/cargo-c/work/cargo-c-0.9. > >> > >> # ls -Tld /usr/local/poudriere/data/logs/bulk/main-CA7-default/2021-09-10_17h13m49s/logs/cargo-c-0.9.2_1.log > >> -rw-r--r-- 3 root wheel 13355735461 Sep 11 14:35:46 2021 /usr/local/poudriere/data/logs/bulk/main-CA7-default/2021-09-10_17h13m49s/logs/cargo-c-0.9.2_1.log > >> > >> thread 'rustc' panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:560:5 > >> stack backtrace: > >> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. > >> > >> error: internal compiler error: unexpected panic > >> > >> note: the compiler unexpectedly panicked. this is a bug. > >> > >> note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md > >> > >> note: rustc 1.54.0 running on armv7-unknown-freebsd > >> > >> note: compiler flags: -C opt-level=2 -C embed-bitcode=no -C target-cpu=cortex-a7 -C linker=cc -C link-arg=-fstack-protector-strong --crate-type lib > >> > >> note: some of the compiler flags provided by cargo are hidden > >> > >> query stack during panic: > >> #0 [trimmed_def_paths] calculating trimmed def paths > >> #1 [lint_mod] linting module `vector` > >> #2 [analysis] running analysis passes on this crate > >> end of query stack > >> thread 'rustc' panicked at 'cannot panic during the backtrace function', library/std/src/../../backtrace/src/lib.rs:147:13 > >> stack backtrace: > >> 0: 0x4704a088 - ::fmt::h62ff206af4f307a3 > >> 1: 0x47113174 - core::fmt::write::h1cff52b8c9dac53e > >> 2: 0x47039e34 - > >> > >> . . . > >> > >> 54: 0x41ec94e4 - > >> 55: 0x4703fbd0 - > >> 56: 0x401361bc - > >> 57: 0x40135cd8 - pthread_create > >> 58: 0x40138b64 - pthread_peekjoin_np > >> 59: 0x40138b64 - pthread_peekjoin_np > >> 60: 0x40138b64 - pthread_peekjoin_np > >> 61: 0x40138b64 - pthread_peekjoin_np > >> . . . > >> 305514048: 0x40138b64 - pthread_peekjoin_np > >> 305514049: 0x40138b64 - pthread_peekjoin_np > >> 305514050: 0x40138b64 - pthread_peekjoin_np > >> 305514051: 0x40138b64 - pthread_peekjoin_np > >> 305514052: 0x40138b64 - pthread_peekjoin_np > >> 305514053: 0x40138b64 - pthread_peekjoin_np > >> 305514054: 0x40138b64 - pthread_peekjoin_np > >> 305514055: 0x40138b64 - pthread_peekjoin_np > >> . . . > >> > >> > >> root 84847 0.0 0.0 15540 6704 1 I 23:09 0:00.14 | |-- sh: poudriere[main-CA7-default][16]: build_pkg (rust-cbindgen-0.20.0_1) (sh) > >> root 680 0.0 0.0 15540 6696 1 I 23:11 0:00.00 | | `-- sh: poudriere[main-CA7-default][16]: build_pkg (rust-cbindgen-0.20.0_1) (sh) > >> root 683 0.0 0.0 6120 3512 1 IJ 23:11 0:00.08 | | `-- /usr/bin/make -C /usr/ports/devel/rust-cbindgen build > >> root 709 80.8 0.1 116812 54448 1 RJ 23:11 362:50.69 | | `-- /usr/local/bin/cargo build --manifest-path /wrkdirs/usr/ports/devel/rust-cbindgen/work/cbindgen-0.20.0/Car > >> root 1882 12.9 3.0 2045144 1970100 1 IJ 23:11 35:48.21 | | `-- /usr/local/bin/rustc --crate-name tempfile --edition=2018 /wrkdirs/usr/ports/devel/rust-cbindgen/work/cb > >> > >> # ls -TldtL /usr/local/poudriere/data/logs/bulk/main-CA7-default/2021-09-10_17h13m49s/logs/rust-cbindgen-0.20.0_1.log > >> -rw-r--r-- 3 root wheel 13910063729 Sep 11 14:36:43 2021 /usr/local/poudriere/data/logs/bulk/main-CA7-default/2021-09-10_17h13m49s/logs/rust-cbindgen-0.20.0_1.log > >> > >> thread 'rustc' panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:560:5 > >> stack backtrace: > >> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. > >> > >> error: internal compiler error: unexpected panic > >> > >> note: the compiler unexpectedly panicked. this is a bug. > >> > >> note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md > >> > >> note: rustc 1.54.0 running on armv7-unknown-freebsd > >> > >> note: compiler flags: -C opt-level=2 -C embed-bitcode=no -C target-cpu=cortex-a7 -C linker=cc -C link-arg=-fstack-protector-strong --crate-type lib > >> > >> note: some of the compiler flags provided by cargo are hidden > >> > >> query stack during panic: > >> #0 [trimmed_def_paths] calculating trimmed def paths > >> #1 [lint_mod] linting module `file` > >> #2 [analysis] running analysis passes on this crate > >> end of query stack > >> thread 'rustc' panicked at 'cannot panic during the backtrace function', library/std/src/../../backtrace/src/lib.rs:147:13 > >> stack backtrace: > >> 0: 0x4704a088 - ::fmt::h62ff206af4f307a3 > >> 1: 0x47113174 - core::fmt::write::h1cff52b8c9dac53e > >> 2: 0x47039e34 - > >> 3: 0x470443fc - > >> . . . > >> 51: 0x4703fbd0 - > >> 52: 0x401361bc - > >> 53: 0x40135cd8 - pthread_create > >> 54: 0x40138b64 - pthread_peekjoin_np > >> 55: 0x40138b64 - pthread_peekjoin_np > >> 56: 0x40138b64 - pthread_peekjoin_np > >> 57: 0x40138b64 - pthread_peekjoin_np > >> 58: 0x40138b64 - pthread_peekjoin_np > >> . . . > >> 320127389: 0x40138b64 - pthread_peekjoin_np > >> 320127390: 0x40138b64 - pthread_peekjoin_np > >> 320127391: 0x40138b64 - pthread_peekjoin_np > >> 320127392: 0x40138b64 - pthread_peekjoin_np > >> 320127393: 0x40138b64 - pthread_peekjoin_np > >> 320127394: 0x40138b64 - pthread_peekjoin_np > >> 320127395: 0x40138b64 - pthread_peekjoin_np > >> . . . > >> > >> For reference: > >> > >> I have higer timeout figures set for poudriere than the > >> defaults. > >> > >> I have since forced the two builders to stop by killing > >> processes. > >> > >> I will be deleteing the log files because of their size. > >> > >> The system is a HoneyComb (16 core Cortext-A72). > >> > >> # uname -apKU > >> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 > >> > >> # poudriere jail -i -jmain-CA7 > >> Jail name: main-CA7 > >> Jail version: 14.0-CURRENT > >> Jail arch: arm.armv7 > >> Jail method: null > >> Jail mount: /usr/obj/DESTDIRs/main-CA7-poud > >> Jail fs: > >> Jail updated: 2021-06-27 17:58:33 > >> Jail pkgbase: disabled > >> > >> # cd /usr/ports/ > >> # ~/fbsd-based-on-what-commit.sh > >> branch: main > >> merge-base: b0c4eaac2a3aa9bc422c21b9d398e4dbfea18736 > >> merge-base: CommitDate: 2021-09-07 21:55:24 +0000 > >> b0c4eaac2a3a (HEAD -> main, freebsd/main, freebsd/HEAD) security/suricata: Add patch for upstream locking fix > >> n557269 (--first-parent --count for merge-base) > >> > >> There are other ports that fail to build in various ways, > >> but so far these two have the only system-wide nasty > >> consequences for their failure mode. > >> > > > > Another one: sysutils/potnet > > > > # ls -Tld /usr/local/poudriere/data/logs/bulk/main-CA7-default/2021-09-10_17h13m49s/logs/potnet-0.4.4_14.log > > -rw-r--r-- 3 root wheel 8463393229 Sep 11 15:39:44 2021 /usr/local/poudriere/data/logs/bulk/main-CA7-default/2021-09-10_17h13m49s/logs/potnet-0.4.4_14.log > > > > thread 'rustc' panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:560:5 > > stack backtrace: > > note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. > > > > error: internal compiler error: unexpected panic > > > > note: the compiler unexpectedly panicked. this is a bug. > > > > note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md > > > > note: rustc 1.54.0 running on armv7-unknown-freebsd > > > > note: compiler flags: -C embed-bitcode=no -C debug-assertions=off -C target-cpu=cortex-a7 -C linker=cc -C link-arg=-fstack-protector-strong --crate-type lib > > > > note: some of the compiler flags provided by cargo are hidden > > > > query stack during panic: > > #0 [trimmed_def_paths] calculating trimmed def paths > > #1 [typeck] type-checking `::fmt` > > #2 [typeck_item_bodies] type-checking all item bodies > > #3 [analysis] running analysis passes on this crate > > end of query stack > > thread 'rustc' panicked at 'cannot panic during the backtrace function', library/std/src/../../backtrace/src/lib.rs:147:13 > > stack backtrace: > > 0: 0x4704a088 - ::fmt::h62ff206af4f307a3 > > 1: 0x47113174 - core::fmt::write::h1cff52b8c9dac53e > > 2: 0x47039e34 - > > 3: 0x470443fc - 65: 0x401361bc - > > . . . > > 66: 0x40135cd8 - pthread_create > > 67: 0x40138b64 - pthread_peekjoin_np > > 68: 0x40138b64 - pthread_peekjoin_np > > . . . > > 196328992: 0x40138b64 - pthread_peekjoin_np > > 196328993: 0x40138b64 - pthread_peekjoin_np > > 196328994: 0x40138b64 - pthread_peekjoin_np > > 196328995: 0x40138b64 - pthread_peekjoin_np > > 196328996: 0x40138b64 - pthread_peekjoin_np > > . . . > > > > More ports that have builds that use what is failing: > > net-im/libsignal-client > textproc/mdbook > > It may be that the poudriere bulk -a attempt requires more > hand manipulation than I'll be willing to put in. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > > -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From nobody Sun Sep 12 16:10:02 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1C04617BAE58 for ; Sun, 12 Sep 2021 16:10:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-21.consmr.mail.gq1.yahoo.com (sonic302-21.consmr.mail.gq1.yahoo.com [98.137.68.147]) (using TLSv1.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 4H6vhh3TZ9z3QcC for ; Sun, 12 Sep 2021 16:10:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631463005; bh=k5iGyTqf43mIGhFWfXq0ZH2CSjG6vYCt1FdE7DTZjrQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mZf3rALNVVnVDqguN4PJywDQIRVJG97Yv7HHZco42Hd64xe4xWhgIIRvp/WqN5m1Vb9NKK+tteW3/2L50g8vapNrVAO12zoVNqmpM3biCWq1G6C6jNWpQQDhmbL5sdIDAzCF3Tyk2+YWI5JdE5tyPYg18MnSH/R4c34bE5b1cRqrgAwJQjX6srn/Tw/cJEhizhXqMTZ46PLp7fyiD+bzq/MyTHKhP3sGc9YDfSQfDNrscg8tbNnFRW0MqQYoLdD2/+BdzcavBimH1pmSZHbSgueqXvp5diBaA1CyBPUn0jPfiZc0vJmjwgp+UOPF2uPnWALFOQFOTRPhYpVLTtgvkA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631463005; bh=pfCyawwEk3yJfrFgWBWue74qhcxCrRvDFRfgW2DgLKi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MAB6qZ8Ko9DFGjZZ1MRQOJsGgMgVltY6m8nb6oARQSK0QxR0z+iPaRA30GHFax5NaJSk2599CUt9m2pw9q2DgTOFtaS5QUuHyQ80pl3GAqXr+AL2e3BdSE4y+dGyMa31KEl+6Cg4uod/jQTlt9/iFcI+Z02i0FVvIXZjn5R3jambU3ssyYs8OyfOXDrtjCkKpd1dfCoEytFnYOyhTX5LMtSs4q4t9TkqMFu7D3ZbU0OhsxvHD/hNamBK1Gy6t1Yoa9VHLCHSvMNYb2cna4G8uwwtqoOD0v5J+vmI2aJDvYLRE5RH6u+Z1i8nG0suGfTgOC5oLxcPePaWcV7vw8wvAw== X-YMail-OSG: ULPVR30VM1nUlkyS.mkwapHkeQIkhERibq.oCwp2lwhyDzdDL4dpPmyGX4CSsVm vn7pEJcq7v3lt_mMpB_qeldCVbu.Z4d4dM1VpkmyxBN7a1nfysJuQsQ5PUVpCeDrcFknQDMDVlFl m2RGzwa3zBebl7fBoXfxUZ9tckpqrTDRjz67DTwkKFVaKUQPrv1tu5TTBIhXvbdjdFPgdtVoaL2u 1gr0CjoNSgliJs775yMluQT.CeUbqQulH0x4VTPqXj2NqnOu3s9WGNQMG64viTiRV.QE_pU_LLxh eMYAPsoMW0CjiqU.7eqSuvifDRkoo5t6KD2gnFpGTJ4bhBz1Sf9bBzeMg0NBJVlC9tCu89dfCPBt Xe8P.aRCnEreFU8.L_qO31eY_zcBy05SN_NpliVoiHJP_GMoj7sl87vKBbv7Nwq1y1eCzJAUItuj 7_joJrPH3ENvA2T4RH7G3kq9qeR03hJQ3I4pBQ76BtF1qEzKKUVg7OJNLut9TypmN9oVOyorY6Ht vAb0r7tBrPUReu0xZ91SjLfj4rKaGZ_WjwhZyjWyq_dfukf8QL3G.Lqxzx_AmbZFg0K2IT2HQs.r 3FMl1KCok5aeoCtGxF7TeCAX03.pNaNTr0IhA8tfEG0kwvSYCXqZrtorkWDzoCBk_U59bSpRM5Z. vGSPYc0i9mSyo9avumVJrRJe4rMDAnfblT34foff0fAg3XoH_fySHEhovTNrxf9R4ncxM8gRWm4N EChJH6a7VnRHI.E8kgMTNqfIQ4nuAWXN82FQc3lj3kQDSZJVL1.gZirw9t7TnIWHSAVhvqXyHVYn O1IEBNtt4hnqCubwobiXYa6aetGnDWOPr3z_fTEZWyE3uiim0e9thepEU9UC1YLiaImV4sF6hxA_ 3jxgm54WoCyeVVPS9o_DKiYr4.s4dufPQtRqteZVq7zpRLtCVKxW0xOBEgQ857Xh_8OiP15.0Yqb nKot6SSzGPR5j45c_pc8fh.YyO0woPEg8y6GFf7ebla7HXjbG.FtSGd5_WwCwvjx5JnVXALHecED 9nOV3FsHQlVNPWZF1YZLtYs4q6BV5SuW.KIzCrQulFZhWNlbZ8jVA0KntofOOVXoAaAOj3Jw8SPV IJWc1fxF0R66_T45JKWQ5nWh3NdQMZjRRlFGF4eRwZUatG.3CRsEPVyzQMnSjnOdKxzSkTR9c57p 9xePUMF23REk09GgwO8kxBuu9Yxobs6PyACbMXFl__7UOW2ZWbxIRonF9kMOOiXr.w0kZcaaQGFp G3FIr_wV07G.5v2o9YhKZI5MNy.RFtUUzLeFQ7en_zPYJ78W.kiJjdUg8HfKl3cQ2JPafkMpT8LP YoKFxeDe3T94hRMh8pMb_Vz_cqDwBadv_epGTdPrer5s.KBbWckySuJ4rFZxXQQgOWkPQw5LbOxV aUorCd9LovxQ.MtV29XG2gLFCUll9lA3j2ypgYR3iAHcM2cONkpj6qKeHMyDSCk9kPv950lP5M5T lO55vNoQbRtUPq7Rmv.wLajYCtOsNFGixD7GUVzjB5Xhb6QcRJ2Vk9qQIIsTcOhVXc9hzYmLgMGi DcwngsBRr5uXJxreqCKwJpJiqQt4bg4O_346NhulP2RzSxQgCQWbS.vVTk0afb6ZaxlcBJlGeAh6 cTmME4Kjel.R3OG8zG0zdSZb9g3nxYB4xZwv4v0X93PTJbpFxSybYKk4qGth0LJsCwN7X5wDryKH Tzb7JFnrsx1j7Mi201MyEn6WXrFZ6sKdvpRtCS3q5ZN38SH6JKqzJOe8ebd87kpRGN4YIk15xyq_ tDx8MEf_8ONo1RLFaF6G40ZSb92BqECxkJEn8VrrDLHtOixU6yugXLhP2Q5SLwVXk80VdyOycc4z lqXgTvQPTQ4Dnz7_nsE1YrVvEq7EzM9c2NFPp.Cqj.2dX.0ObwcZnr4VQsiFGyAG0oTk5JwkZff5 _nqrmHfYdR.TPaRCvFQh3rZfQPV.f4wKstDXtWMSHV.FQfc7_sXjO9hXxgusu8cpf5SwlS54litW _H1JFgJOdJxQ74tLqpsHxluS1birjjgSk4_G78yOkUj.62pAT1LYfCAkeBKbSg9_dFpHihOkYtNG vqeb0WdgNcJ2yZyBZ56uA.3aTIjdnw9kkaxCHjLOWVpZHy.6zf4aiA7vXRAOqfUvMN.RBdCcEWjD _CtBfhqhqTnNPgUTrdMV7ltPWIRjvFqRi5tDzFAnD.VUSgNQ.Q7.S0uQWR..l8cZOPs55zCbqBdr RcPj0mhRKjYP_FkPvPYKvDd.ovBb_vPKtQ_PrhQ_NYY2E3kpBu.VnmYSZFA47evtqRr4VGZyBdIH UD5LKs0znea9NA6gS.fk0qdNtZuW4dP4PcXKEYm8pnHerEalE3JRT1D9KFAl1Vg8of4r8 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Sep 2021 16:10:05 +0000 Received: by kubenode522.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c2e03098900df9d550c98009ecde6623; Sun, 12 Sep 2021 16:10:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Python2.7 seemingly stuck on RPI3 In-Reply-To: Date: Sun, 12 Sep 2021 09:10:02 -0700 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4H6vhh3TZ9z3QcC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=mZf3rALN; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(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)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.147:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(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]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.147:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N [This is a resend now that I'm again subscribed to the freebsd-arm list.] From: bob prohaska =20 Date: Sat, 11 Sep 2021 12:34:40 -0700 : > A present attempt to compile www/chromium on a Pi3 using > a single make job has gotten stuck in a curious way:=20 >=20 > Python2.7 appears to be stuck, or nearly stuck, reading > swap. The machine isn't out of swap, in fact swap isn't > even very busy, around 85% for the hard disk partition=20 > and 15% for the microSD partition. Queue lengths are=20 > small and kBps close to 1000 for both.=20 >=20 >=20 > Here's a sample of disk activity: >=20 > procs memory page disks faults = cpu > r b w avm fre flt re pi po fr sr mm0 da0 in sy = cs us sy id > 0 0 13 2560404 57968 2546 103 83 35 2505 6020 0 0 20952 = 862 6525 19 4 78 > dT: 10.009s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 0 147 147 944 0.9 0 0 0.0 0 0 = 0.0 13.6 mmcsd0 > 0 147 147 944 0.9 0 0 0.0 0 0 = 0.0 13.8 mmcsd0s2 > 1 144 141 878 6.6 2 76 31.8 0 0 = 0.0 85.9 da0 > 0 147 147 944 0.9 0 0 0.0 0 0 = 0.0 13.8 mmcsd0s2b > 1 143 141 878 6.6 2 76 31.8 0 0 = 0.0 86.0 da0s2 > 0 2 0 0 0.0 2 76 31.8 0 0 = 0.0 0.6 da0s2a > 1 141 141 878 6.6 0 0 0.0 0 0 = 0.0 86.0 da0s2b =46rom what is presented, I'd guess that da0s2b is on spinning rust. My expectation is that da0 is spending much of its time seeking and the system does not have much to do during the seek activity. So the sum of the latencies is adding significant time for any given amount of progress.=20 Be careful of interpreting %busy as I understand. But the 86.0 or so figures suggest not to expect getting much more. This all fits with the mmcsd0s2b activity for about the same use looking like could go faster. Note the 0.9 ms/r for mmcsd0 vs. the 6.6 ms/r for da0 as well as the < 15 figures for %busy for mmcsd0. Splitting the swapping/paging load across wildly mismatched media bottlenecks on the slower media for the interlaced accesses from what I can tell. Such a mismatch undoes any advantage from dual channels from what I can tell. Seek time is one of the reasons that I avoid spinning rust for machines that I do builds on (and more generally then that, but not universally). Fragmentation is less of an issue on the kinds of media that I use. For small arm boards I tend to use media that supports both USB2 and USB3 use, for example staying within power limits in each context but able to be fairly fast for USB3. I have access to Samsung Portable SSD T7 Touch 1TB's for such use in modern times. (I've not switched all the contexts over yet. The older type of media that I'd access to is not always purchasable these days --and is slower for making duplications as backups or the start of a small variations.) I've also been using T7's as alternate external boot media for bigger machines, such as being able to boot and operate any of: HoneyComb, MACCHIATObin Double Shot, RPI4B (8 GiByte) via the same external media. I make no claim that the T7's properties are unique for such issues. The T7's just happen to be what I've used. Handling the power issue as I want eliminates many products for me. (I avoid USB hubs when I can for the small arm boards.) > Sat Sep 11 12:01:49 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 882800 960400 48% > /dev/mmcsd0s2b 1843200 880600 962600 48% > Total 3686400 1763400 1923000 48% >=20 > Here's a sample of top output >=20 >=20 > last pid: 41683; load averages: 0.04, 0.13, 0.15 = up 15+17:47:00 12:02:29 > 48 processes: 1 running, 47 sleeping > CPU: 0.1% user, 0.0% nice, 0.7% system, 0.7% interrupt, 98.5% idle > Mem: 429M Active, 23M Inact, 182M Laundry, 222M Wired, 87M Buf, 44M = Free > Swap: 3600M Total, 1711M Used, 1889M Free, 47% Inuse, 3784K In >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND > 24726 root 1 20 0 1566M 627M swread 1 7:36 1.83% = python2.7 > 1074 bob 1 20 0 14M 1100K CPU0 0 39:03 0.14% = top > 881 root 1 20 0 12M 268K select 0 6:49 0.02% = powerd > 1069 bob 1 20 0 20M 684K select 0 3:28 0.02% = sshd > 942 root 1 20 0 20M 644K select 3 3:18 0.00% = sshd > 24504 root 1 41 0 370M 356K select 2 1:17 0.00% = ninja > 945 root 1 20 0 17M 972K select 2 1:04 0.00% = sendmail > 827 root 1 20 0 13M 616K select 2 1:03 0.00% = syslogd >=20 > Admittedly, 1700M of swap is a lot in use, but in the past the machine > was able to work through much higher swap usage. Now it seems well and > truly stuck, though still reasonably responisve to keyboard input. > It's unclear to me if this is my error or something else. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Sep 12 18:37:25 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 68F2317CF6CD for ; Sun, 12 Sep 2021 18:37:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.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 4H6yyr44J1z4pny for ; Sun, 12 Sep 2021 18:37:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631471852; bh=Ikw/KukU0WxjtxZb40M7gU1rkd91+7aSwqajOBI5sKs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=j7zDuOfpy9zt8BOckbw1iE9BbEyifyzS47dIQEDLi081I2LHtwxW6YcoYMFp/q8O6Aok58yhHhGQ3h1IZiPu+3zcxfbrPQvw2CZ/MPyu+fKrmXDMzSqZgXNEur8ZNlgYqY+O2PcE3hNMv6iEW+j16RE7XYiiDhurfZNY2no+JTjfZa4SWsSmsVSLdfYWVreOnuAjW5qH2Xe9AkiMbYeSA5DSJtSr4/f+SBMvZsxdbWUclchsafrhWjmUPyiacSnuv0cG6ulaW+mCfjXoB+4jzWAK/8JJ2Hvg8aYrbZtlldUW4/HrqkOyg9T4+zVr45vf4v4Y+eml0W4u/iqbF5PPgQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631471852; bh=dhfFyb7FKC52cCvThLrySFVHgBpc7Q71aK2VB+KGcjt=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=qczRymT0vHD4bRiJTvJ7up5O+lx++ATx0MFXUFxn86+/QhLiDM1FKI6yUU4TBSjHW2ohyoUszSXLYnWgaEQan/ayZ91GCRz7U/4MGNm/HEIX/wbuabw+padpizE1a2IXgUkpTbqri6GsQZ4Z4LedDIklfPsTCaZxAVkVMYdeaY8R80DGCcKE/MqK9cjhlZFYYa7pzXy2b+VKU5FyBJ7NNJrlkGRdgnZ5dtGS1aWs6ZdnejYP5dGWJXW2HT+D9ygzcYP+PZfC/7sLHIZze9HXZLhNUePyW7MLDwmMlhdS5i2edy4ctzhfM2LQRzb135WseMbrgYP3zDCMAOopzs7inw== X-YMail-OSG: 2BCq0C4VM1nOBRbEyuXyu2SXwwYb1Ag.aY2BL6tjzNoEFDijYHQcY8G7Ysxfac5 VWihaqjCPQq8OMHqXUVIYP6bhhtoB0S5rUdbH2pBCcuuzglzOCS.btqvEUfrj5yugd011SAGmf.7 VXq2TR3cRJsTaNKUh8UX3ul8axCuUFxd.eOPkMYjb5YXwOYGy5S3.wLmHIbGWztyMkvCbmccwnNR bR4saYFZVJRzZuI7iH_uPUbVOa47.29m11kZhkK2abcYDgAsaisk58hpseZFbucZLADo4wVy.Ika 8haVwXQVRNwNnOosg11sdDPhmwcSSYSY3NbPYruhM3pmJaUsOylgwUASxvp57B7_qUYrmc0l3Old 6PkYp9yMwNEktFTWt0BFTVmoIyELr35qt6Qv.9jhiLdHkacansyjcVbMgh9g3Lrk9QUiY.NYofZ4 j6gqrr.SizUOGgTCnb1giT3C2KROv89TxkJVT8FRqtoF4V27jtdxxGlmacVtzrLBTiGqKBeoWogQ ioiaR.4PBwUro2jQa9F0_jND4PtCMSLCAHqQzsbqKR7lhygS6HV6rBQB4lc6cJT9UjcD8hsgmVzf wgjzHCO81vx_Vy4CzkXaHRbriBYvuNPlf.KRMIVTNRG74wUT98MVELxBRtQSA53u.hapqFh8v6on JzCmyBWbP1o5DGSPwizXw2UhKzRHlvZtzugo.7qEU4qJpNXAYbN1SJlmaJFzns4QJfZ102uyo.iE 5SsZtlV1iT.ZVRmEMEAO50zkW6Z5Qt5uJo0QCTfOcKca.pTY5N7ig7m0Sb8LKbIS4Wm0VnmZM1UU TCTeFAbPS8jU8hnID3JoZbvOeV94iiXRXGNp65ntq9ArGCIvjCqKzOVMbv_K6Lv7rTCk6.nV3u2C gjKYB1hgFfvT6FJGfS5tEhLAh8nY6lzCEXRsLXOi82I6H0MHhgA1ciujqo4yFUEyxk9f9Wl5tu1n BVSKmpwbbcc.dn5QvztSWnEB8JRuGOkRZpvws7Env2zQ_J1bUaHhnUq.TYTLOt2rk_wrA.dkmgQ_ Tpp2ischHjv2CBd9Cl96JrD69_5acesSGAyUxJeWkaEVIaSoIDS9Z.ArHoQHTR1TGgCmNLG8OxuQ TqDV_1xsUqnx9_XEdT3SJv0EevdjOeTac_h3YJxWANLIdBWtkmIQUlDEiTN8ds5aYw5IAc29kIK7 z5ljhjqqY7rqwdAiyoyqc5Y.wh6wuS3SDQlgjZTD2Vh3g5O9h3I_zeZBmndnenJ09Crg2dPD.ur. 0Y07jUPjApBrOBhpo28Q8kMtCCf7tEGE6CaCc1tGNeG8bVpek2rX03zzygi8jqZWfbIVERm0is_O X0ZPrWC1ZCMscu0aDLjg4kyCgSlcs5gDN.01nM9C3AVypzgrEhCgpixvtStPp.QJz_1TDbSXmwUa FED6hdAIBfFkrn0YHjAZ8NKN6swcHyXkuUD1gVuAaAvzejriPtfMT6FK1vCosbaZgRbts4mR6pBs 4z537_Vi0000VXkL8kaUxJ.IQKzSH99a0V8sx1yZJEXyw015IIaHIVuI4r4ipaVRV4vL3vVqrMl_ rkBX6IL29lYlzRBZF03CrjWl.xaFhHa8RlFgCZZv4HQTe69.FOLf.z6l0Z1zbq5Z7MLaF8ZSrmsw FumWQZE_cYPN_P3ju0hWFBh0PV3MyKvfff1rWqHt8ZYgd42pB.eV3E30At4LFPBB4sw2FQR_PnJA ZgoMPAHy10JyH_JVHYgVcLQOfquQYNzzUIMaXikHz6s0dXmuAmD2fH1.MtAMbsXCnTN2K8IWqDHQ gf1yXte2Db.eLuM9cGw1WHSFV9H5cQnNmEHs8VIjadozFFR8JB.mW4evYtSXKZUkvmrk.5S5eEDE oVmfinf3tly9v8S4H2mVd51MaGSQxLW0KC0NI9cWIfsUsBlGgWMm7seCoxbvWKTjxec47e_HBsmt H97BEXK5Vwfonwufbpm_CANMDbjpEoMISWNbc8.SoU8IXsPODwd5KOp4jdFAFh5od3HAHnfurvpl q1aObjS1ZI0FHp3MvIwxHS6t3wZPscfuUdzeDVJjaWAJwcbvs1UUGYMoHQ_WOOltzMUBhAUPMvAy lk7V7TnUiTDidY5aO0WQDuhJM0d8jwQv5Ja6AdQIh3Y_XTPif3_azFRCJ6cDls61WP2K631wkAxn Lqxq9B2CjgwjN0spLKssiuJw4xvw0L3.1mPoYty2Prl2ZLdLsd_1vtGtfURfPhRXnvJzXmCnrRbf xQ4YgkGFSRap4rrUjt2gUZns3__k5f4JntQaDrLpOjRa_jVh.zuJ8De5U9n97pbFR8rp46zvBrlM X14EsaxFQGrji4J6G X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Sep 2021 18:37:32 +0000 Received: by kubenode500.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a7567cc7e39562b2d72b7468578765e6; Sun, 12 Sep 2021 18:37:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: aarch64 poudreire-devel targeting armv7: misc/freebsd-doc-el and the like are building (Latest ports using main [so: 14] FreeBSD) Message-Id: Date: Sun, 12 Sep 2021 11:37:25 -0700 To: Free BSD , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4H6yyr44J1z4pny X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=j7zDuOfp; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(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]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N I note that the misc-freebsd-doc-* (via -en as a master) are marked = with: BROKEN_aarch64=3D fails to build: Exception in thread "main" = java.lang.StackOverflowError at = org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:180) and other issues make them skipped in the oficial builds via amd64. However, my ongoing poudriere bulk -a got: [41:38:52] [03] [17:23:19] Finished misc/freebsd-doc-el | = el-freebsd-doc-20210125,1: Success (That is the first such to finish.) This was via: # poudriere jail -i -jmain-CA7 Jail name: main-CA7 Jail version: 14.0-CURRENT Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/main-CA7-poud Jail fs: =20 Jail updated: 2021-06-27 17:58:33 Jail pkgbase: disabled # pwd /usr/ports # ~/fbsd-based-on-what-commit.sh=20 branch: main merge-base: b0c4eaac2a3aa9bc422c21b9d398e4dbfea18736 merge-base: CommitDate: 2021-09-07 21:55:24 +0000 b0c4eaac2a3a (HEAD -> main, freebsd/main, freebsd/HEAD) = security/suricata: Add patch for upstream locking fix n557269 (--first-parent --count for merge-base) # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 = main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Sep 12 21:00:05 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 88E1917C5DCC for ; Sun, 12 Sep 2021 21:00:06 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H727B0MWJz4VJS for ; Sun, 12 Sep 2021 21:00:06 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id DEBE31A8AD for ; Sun, 12 Sep 2021 21:00:05 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 18CL05Dk003438 for ; Sun, 12 Sep 2021 21:00:05 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 18CL05bQ003437 for freebsd-arm@FreeBSD.org; Sun, 12 Sep 2021 21:00:05 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202109122100.18CL05bQ003437@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 12 Sep 2021 21:00:05 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16314804054.48b0b.3312" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: Y --16314804054.48b0b.3312 Date: Sun, 12 Sep 2021 21:00:05 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 239673 | Spurious Interrupt message from /dev/led/led1 Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 3 problems total for which you should take action. --16314804054.48b0b.3312--