From nobody Fri Aug 25 09:21:33 2023 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 4RXDwt1LhBz4r6Ms for ; Fri, 25 Aug 2023 09:21:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RXDws6192z3f9S for ; Fri, 25 Aug 2023 09:21:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692955306; bh=GmahZgEvkzuH/FQXJOuFXYDQVGgJJLrxPjfr2s9lglo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=i5cjHnbWWUIWTIw5faKRhq3vCCVmQzgUumfIqQ2Zr9xfcW3s+dgokAzOQLIRbS4FRsywE5WnUe/9qHeJ2eQAIfjsx+1q85en07zqiS6/KpMCxqTGE7eiqH1NYYb9z5Zruf3Hg6RyfYfCsZHMqw4G2OZO+smE4cxDeiazgDMGSQdtC2qzduHw1LpRwHCBLehYS9yuPLcvQtN9kqTog3Fez3+lnnpsJFcsL1SQyNBZ3Jvfo3sUYjTCbeW7eZnIPFVl/8pf9pu6Zh1EH/cNNJMuue2NjEgfJRjtLDsMlPTaTsmreLMpairpSR1vZJAzrW5duaI+t7JJKJc/wTkQCcUaiw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692955306; bh=TK9UmyAg7UXiCWLz+DzrYzrGF/1JhBTW7fDi88gAlSh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Bw0uU+2pK8RB7F5O2b/0314b7ytprxgjbi+UtjeRdzJCp1I5L5MKuBpeNsAGRLcn89ZU4s1jD0ijxEKLC6cFXaeH4SaTCGv262ExQ2XpIKTVzCJHtQhXuBBgTCyIStO7YtcUixH8syLggJwM7MY70hTj9pZ6jOZxx2brGb84BtFc77upXs88L2Axx2n9WZzUr37qRKaT09YzmJ8yh+sFwBWUqzNPddZW0lht6eRC7RgkMAWx7r2PxJYfuw9EjyXLB15tYZ1lBI91S8LyeSotv5W1SFRuHjYGcxGrIA5D2ZSC2Fbyn39GZL1lKdiQXwlwguMsIJ2mzVesrgtIyjEKCw== X-YMail-OSG: I6SaPP4VM1kDFTU7tOdeKJMo6WeWSluFD5izrsd2lEGaaJfpuqC7Ppo2oluj0Ed 673iOvQyInQG.O3Dyi1El5LV3mSBwmYEi1qe6SurXu5THrlg57w6YXpytnTNneW_KWm3nvywoemj JUXB7IyyeoIxpgFJUryO.vzCzCFSt9iYedAH0etokDOOm7nCECK5DrKSRCAkSYf0P_n_EfJML9aC EuW.EKYL1_K28Q9Ebqp4IlQ9cwrhDflSguvZorYU7.7kgY1O32Dt4W.qaug2Akwd5HndvKN8Lm1r CJwHemvCp_xbWOf_O1TCIW6Y3UEJEyGiGWT.iSoj5uwGxgG0kqFAsUyT2WK0Y4AyHLg2CLCz0V5P 7K1sBFKo6hoKfUca8vwJMrQPTxOM_uhGSKG4shC5tcy_h2X_BUFqK5Kf.BIdgSK6KP5FfCn4iN8k _ebPSbzIw62ES7HBs1Pek2LquZAwfQM5i0vSa3L7Sd7BQQWiJoI8jiNQPVigJXlBg6YwBiIvtZ4o 5KJlnKOzJYh3sIBpBr6qP5ineV2lnIENCPht3WQ.OrYYtE7L0RWGWvoiEBPRBgxG9pf8XLeGYHZx N11OzoXCSAGEFBcbCJ2prZceJn7w7slmDEBwgZaTZ_NyV375xeka2.fPvRRNYzp2Fa1KRMdIs4MI FSmbqtG546qWaUsShYKYCP3SOZvyzZ4c94mgcIAsRWPL_NVWpOj1Mv88Szchw4RKUNFJellroQa1 QibiG3pMIXabjFGJ44eyz6M8BxN1z3NBnGr4ieFLi8TMVBZDoQ5CXQ2VwkbfbVLlt.1aAuJeH5S_ qcxPIYkH72lDJu_z_tsWN9Mqbp7bCiVXkLu14txKswm5FGIXBMlj_KLQU36dKf2GC3kxJJw.OQR2 o4elS8Jt_pzD0UpQ0o6cTXFpXL6gSl.spBKtZclH63NIDdsXi2.4F7PAls7nyWPf0CLdEMFhhLiV VMrO_pG0CwPb6_QDZvXPXlnFGkdVCQNeTnnqS159uZvgiGz3n.YuGoDp_yLhncmCmkzO_9M4pH_R pRGE1GZRzgyUuS2Lau.yDdLmK7kEW56iDy62qSDVEUy.OXmQ59mAbmssJ.i5O43N6LjXEPPSAv81 8EX9.Qvsb5udYtIwTFFKBg7ilrTquddj3vo8Pbd2gGWUi_cSTmPoFrjJxVsKaMOsNGDEqEaFXxGT fUMfK7uvJYXiA7CDy4lqqA278ZxrmTBWd.Bk37xcEQwS7hYT4WyYybkpSwbMYkpWyH_0aM_MURMd SpBlyGWpTw0PK4gBQtB61aah6N9w0Sq73ZBPWHHsDY6mDTJFmerFW7w7Oz6SJOlDLESriPXydBTR X3a1mE6M7gxu7SbRdFpceY2313K_69xNh4BO2hUfcu8H0DzZmdCdrsYxdpfw5ogwVrbaxNks0rJo EdGfpMe3rWQuImHrCyr2RHcQVvhauT5qLC06FMKI9Aq0buapVmkOnfNgpMmxH2TXFHkJCWAVYBIZ 0369ycKuMkVNRT526N03SxZdh8xUIcGOTO3pa6XbvaKuD0gzoMFFTJfMdIdPdaIIYlbihzjUbI3n bJ1FKBwASXHId_vF0WNTj1yS.aLjf6G4qz2m8gpM74K9djmVxVgs6esCZEbbf22nRFjLULE3sDiC 1boG8OvbblIbPjxH3vzZ4DTmHGWz.s0BDDLYjPfP_rbQMU_3ls2I9kb.gSGnl3bJ3eDTa4qZ_KAz ieQG8viHw3L0VonZg_jbwuBinKBIfWC7Im67mglXLLKt8lBkhmoaWKhmPpYxDOMlNPQ4Z1cG2DYI gH6ika3hA4yRCaWDwq8n85VoPt_iifOT4AWJdsRG3tMj4opQrFwe_Xdl9sKJHMQ1S8PxRXntOakT k32lLY_ocezhOjefgP4l3SLYdGCgO8X3DhTevcXiuwKiVqc.nncDClg4ydJXa6Fk.ec7dxuE88nP ldOHtXvESpz9xPFQxEVr0bjLedmFzgpDZBGpFe0M_hru8aV4kodg31usxy_fHzDPuyuRWfzPZU__ lmilUw5EwjwNvo8pJfRFuwburRC2oCo2bBzuUZSO1HePHUkNUqmj3c550nc34iRf6iZenuTmK0C3 vGoSOxU3_.FjQBwk0a30PgfI0TylJYBrgW9yzZLb6ADeS08l_zMB47.Is40s3DiJty7HoQ_aJABF IYoUejDIvULK6JtHXlQvuj2dBWOSqvPO6g26CP8habLFkPqW0c_sg_Kkt1A5OsTqTY9ZQQdO2zlK .lTJ__eil6c3wYe0EV3bh67vvFAaAiOQ9vW7P9vF2I0AiR1Wvnw_FjULSWxGDg9nEHlJTF4_Vt_P Bfp4- X-Sonic-MF: X-Sonic-ID: f917baca-d30e-4667-9bad-2eb2c1c22601 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 25 Aug 2023 09:21:46 +0000 Received: by hermes--production-gq1-6b7c87dcf5-9dzwt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ac5e9bae4323d5f3ea8d390ba87d248b; Fri, 25 Aug 2023 09:21:44 +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 16.0 \(3731.700.6\)) Subject: Re: www/chromium will not build on a host w/ 8 CPU and 16G mem [RPi4B 8 GiByte example] From: Mark Millard In-Reply-To: Date: Fri, 25 Aug 2023 02:21:33 -0700 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <73355E51-CF0A-4397-8B63-92A4497F1090@yahoo.com> References: <804E6287-71B7-4D2C-A72C-6FA681311139.ref@yahoo.com> <804E6287-71B7-4D2C-A72C-6FA681311139@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RXDws6192z3f9S X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 24, 2023, at 21:57, bob prohaska wrote: > On Thu, Aug 24, 2023 at 03:20:50PM -0700, Mark Millard wrote: >> bob prohaska wrote on >> Date: Thu, 24 Aug 2023 19:44:17 UTC : >>=20 >>> On Fri, Aug 18, 2023 at 08:05:41AM +0200, Matthias Apitz wrote: >>>>=20 >>>> sysctl vfs.read_max=3D128 >>>> sysctl vfs.aio.max_buf_aio=3D8192 >>>> sysctl vfs.aio.max_aio_queue_per_proc=3D65536 >>>> sysctl vfs.aio.max_aio_per_proc=3D8192 >>>> sysctl vfs.aio.max_aio_queue=3D65536 >>>> sysctl vm.pageout_oom_seq=3D120 >>>> sysctl vm.pfault_oom_attempts=3D-1=20 >>>>=20 >>>=20 >>> Just tried these settings on a Pi4, 8GB. Seemingly no help, >>> build of www/chromium failed again, saying only: >>>=20 >>> =3D=3D=3D> Compilation failed unexpectedly. >>> Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to >>> the maintainer. >>> *** Error code 1 >>>=20 >>> No messages on the console at all, no indication of any swap use at = all. >>> If somebody can tell me how to invoke MAKE_JOBS_UNSAFE=3Dyes, either >>> locally or globally, I'll give it a try. But, if it's a system = problem >>> I'd expect at least a peep on the console.... >>=20 >> Are you going to post the log file someplace?=20 >=20 >=20 > = http://nemesis.zefox.com/~bob/data/logs/bulk/main-default/2023-08-20_16h11= m59s/logs/errors/chromium-115.0.5790.170_1.log >=20 >> You may have missed an earlier message.=20 >=20 > Yes, I did. Some (very long) lines above there is: >=20 > [ 96% 53691/55361] "python3" = "../../build/toolchain/gcc_link_wrapper.py" = --output=3D"./v8_context_snapshot_generator" -- c++ -fuse-ld=3Dlld = -Wl,--build-id=3Dsha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now = -Wl,--icf=3Dall -Wl,--color-diagnostics -Wl,--undefined-version = -Wl,-mllvm,-enable-machine-outliner=3Dnever -no-canonical-prefixes = -Wl,-O2 -Wl,--gc-sections -rdynamic -pie -Wl,--disable-new-dtags = -Wl,--icf=3Dnone -L/usr/local/lib -fstack-protector-strong = -L/usr/local/lib -o "./v8_context_snapshot_generator" -Wl,--start-group = @"./v8_context_snapshot_generator.rsp" -Wl,--end-group -lpthread = -lgmodule-2.0 -lglib-2.0 -lgobject-2.0 -lgthread-2.0 -lintl -licui18n = -licuuc -licudata -lnss3 -lsmime3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -ldl = -lkvm -lexecinfo -lutil -levent -lgio-2.0 -ljpeg -lpng16 -lxml2 -lxslt = -lexpat -lwebp -lwebpdemux -lwebpmux -lharfbuzz-subset -lharfbuzz = -lfontconfig -lopus -lopenh264 -lm -lz -ldav1d -lX11 -lXcomposite = -lXdamage -lXext -lXfixes -lXrender -lXrandr -lXtst -lepoll-shim -ldrm = -lxcb -lxkbcommon -lgbm -lXi -lGL -lpci -lffi -ldbus-1 -lpangocairo-1.0 = -lpango-1.0 -lcairo -latk-1.0 -latk-bridge-2.0 -lsndio -lFLAC -lsnappy = -latspi=20 > FAILED: v8_context_snapshot_generator=20 That FAILED line is 64637. > Then, a bit further down in the file a series of=20 > d.lld: error: relocation R_AARCH64_ABS64 cannot be used against local = symbol; recompile with -fPIC > complaints. The first R_AARCH64_ABS64 lines is 64339. After that are the next 2 = lines, with: defined in = obj/third_party/ffmpeg/libffmpeg_internal.a(ffmpeg_internal/autorename_lib= avcodec_aarch64_fft_neon.o) and: referenced by = ffmpeg_internal/autorename_libavcodec_aarch64_fft_neon.o:(fft_tab_neon) = in archive obj/third_party/ffmpeg/libffmpeg_internal.a > Unclear if the two kinds of complaints are related, nor whether = they're the first.. >=20 >> How long had it run before stopping?=20 >=20 > 95 hours, give or take. Nothing about timeout was reported >=20 >> How does that match up with the MAX_EXECUTION_TIME >> and NOHANG_TIME and the like that you have poudriere set >> up to use ( /usr/local/etc/poudriere.conf ).=20 >=20 > NOHANG_TIME=3D44400 > MAX_EXECUTION_TIME=3D1728000 > MAX_EXECUTION_TIME_EXTRACT=3D144000 > MAX_EXECUTION_TIME_INSTALL=3D144000 > MAX_EXECUTION_TIME_PACKAGE=3D11728000 > Admittedly some are plain silly, I just started > tacking on zeros after getting timeouts and being > unable to match the error message and variable name.. >=20 > I checked for duplicates this time, however. Not stopped for time. >> Something relevant for the question is what you have for: >>=20 >> # Grep build logs to determine a possible build failure reason. This = is >> # only shown on the web interface. >> # Default: yes >> DETERMINE_BUILD_FAILURE_REASON=3Dno >>=20 >> Using DETERMINE_BUILD_FAILURE_REASON leads to large builds >> running for a long time after it starts the process of >> stopping from a timeout the grep activity takes a long >> time and the build activity is not stopped during the >> grep. >>=20 >>=20 >> vm.pageout_oom_seq=3D120 and vm.pfault_oom_attempts=3D-1 make >> sense to me for certain kinds of issues involved in large >> builds, presuming sufficient RAM+SWAP for how it is set >> up to operate. vm.pageout_oom_seq is associated with >> console/log messages. if one runs out of RAM+SWAP, >> vm.pfault_oom_attempts=3D-1 tends to lead to deadlock. But >> it allows slow I/O to have the time to complete and so >> can be useful. >>=20 >> I'm not sure that any vfs.aio.* is actually involved: special >> system calls are involved, splitting requests vs. retrieving >> the status of completed requests later. Use of aio has to be >> explicit in the running software from what I can tell. I've >> no information about which software builds might be using aio >> during the build activity. >>=20 >> # sysctl -d vfs.aio >> vfs.aio: Async IO management >> vfs.aio.max_buf_aio: Maximum buf aio requests per process >> vfs.aio.max_aio_queue_per_proc: Maximum queued aio requests per = process >> vfs.aio.max_aio_per_proc: Maximum active aio requests per process >> vfs.aio.aiod_lifetime: Maximum lifetime for idle aiod >> vfs.aio.num_unmapped_aio: Number of aio requests presently handled by = unmapped I/O buffers >> vfs.aio.num_buf_aio: Number of aio requests presently handled by the = buf subsystem >> vfs.aio.num_queue_count: Number of queued aio requests >> vfs.aio.max_aio_queue: Maximum number of aio requests to queue, = globally >> vfs.aio.target_aio_procs: Preferred number of ready kernel processes = for async IO >> vfs.aio.num_aio_procs: Number of presently active kernel processes = for async IO >> vfs.aio.max_aio_procs: Maximum number of kernel processes to use for = handling async IO=20 >> vfs.aio.unsafe_warningcnt: Warnings that will be triggered upon = failed IO requests on unsafe files >> vfs.aio.enable_unsafe: Permit asynchronous IO on all file types, not = just known-safe types >>=20 >>=20 >> vfs.read_max may well change the disk access sequences: >>=20 >> # sysctl -d vfs.read_max >> vfs.read_max: Cluster read-ahead max block count >>=20 >> That might well help some spinning rust or other types of >> I/O. > There don't seem to be any indications of disk speed being > a problem, despite using "spinning rust" 8-) Nope: R_AARCH64_ABS64 misuse is not a disk speed issue. >>=20 >>=20 >> MAKE_JOBS_UNSAFE=3Dyes is, for example, put in makefiles of >> ports that have problems with parallel build activity. It >> basically disables having parallel activity in the build >> context involved. I've no clue if you use the likes of, >> say, >>=20 >=20 >> /usr/local/etc/poudriere.d/make.conf >>=20 >> with conditional logic inside such as use of notation >> like: >>=20 >> .if ${.CURDIR:M*/www/chromium} >> STUFF HERE >> .endif >>=20 >> but you could. The actual R_AARCH64_ABS64 use is in: = obj/third_party/ffmpeg/libffmpeg_internal.a(ffmpeg_internal/autorename_lib= avcodec_aarch64_fft_neon.o) not directly in chromium. The solution is not clear to me. > That wasn't needed when the Pi4 last compiled www/chromium. > A Pi3 did benefit from tuning of that sort.=20 >=20 > It sounds like the sysctl settings were unlikely to be=20 > a source of the trouble seen, if not actively helpful. Yep, the sysctl's were not relevant. > For the moment the machine is updating world and kernel. > That should finish by tomorrow, at which point I'll try > to add something like =20 >=20 > .if ${.CURDIR:M*/www/chromium} > MAKE_JOBS_UNSAFE=3Dyes > .endif >=20 > to /usr/local/etc/poudriere.d/make.conf That will not help avoid the R_AARCH64_ABS64 abuse, unfortunately. =3D=3D=3D Mark Millard marklmi at yahoo.com