From owner-freebsd-arm@freebsd.org Mon Dec 28 04:48:50 2020 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 9942C4D0F5A for ; Mon, 28 Dec 2020 04:48: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 4D44nX5ytRz4ggY for ; Mon, 28 Dec 2020 04:48: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 0BS4menx028390 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 27 Dec 2020 20:48:40 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 0BS4mejC028389; Sun, 27 Dec 2020 20:48:40 -0800 (PST) (envelope-from fbsd) Date: Sun, 27 Dec 2020 20:48:40 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Migrating from -current to stable/12 on RPI2B (ARMv7) Message-ID: <20201228044840.GA28380@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4D44nX5ytRz4ggY 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)[]; 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]; 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]; 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]; 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: Mon, 28 Dec 2020 04:48:50 -0000 Having a bit of trouble migrating to stable/12 from 13.0-CURRENT=20 FreeBSD 13.0-CURRENT #3 r368820: Sat Dec 26 19:01:50 PST 2020 =20 bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC-MMCCAM arm This is on a Pi2B v1.1 The MMCCAM kernel option was added for sake=20 of the experiment and hasn't, up to now, been accompanied by any visible problems. World and kernel have been built many times, no problems.=20 Buildworld keeps stopping at --- clang.full --- c++ -O -pipe -fno-common -mlong-calls -I/usr/obj/usr/freebsd-src/arm.armv7/= tmp/obj-tools/lib/clang/libclang -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/o= bj-tools/lib/clang/libllvm -I/usr/freebsd-src/contrib/llvm-project/clang/in= clude -I/usr/freebsd-src/lib/clang/include -I/usr/freebsd-src/contrib/llvm-= project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__ST= DC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DNDEBUG -DLLVM_DEFAULT_TARGET_TRIPL= E=3D\"armv7-unknown-freebsd12.2-gnueabihf\" -DLLVM_HOST_TRIPLE=3D\"armv7-un= known-freebsd12.2\" -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/freebsd-src/arm.armv= 7/tmp\" -DLLVM_TARGET_ENABLE_ARM -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeAR= MAsmParser -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter -DLLVM_NA= TIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler -DLLVM_NATIVE_TARGET=3DLL= VMInitializeARMTarget -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInf= o -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sections -f= data-sections -gline-tables-only -Wno-format-zero-length -Qunused-arguments= -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/include -fno-exception= s -fno-rtti -std=3Dc++14 -stdlib=3Dlibc++ -Wno-c++11-extensions -Wl,--gc-s= ections -static -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/lib -o= clang.full cc1_main.o cc1as_main.o cc1gen_reproducer_main.o driver.o /usr= /obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libclang/libclang.a = /usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm/libllvm.= a -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libz -lz -L/usr/ob= j/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libexecinfo -lexecinfo -L/usr= /obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libelf -lelf -L/usr/obj/us= r/freebsd-src/arm.armv7/tmp/obj-tools/lib/ncurses/ncursesw -lncursesw -L/us= r/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libthr -lpthread -legacy ld: error: failed to open clang.full: Cannot allocate memory c++: error: linker command failed with exit code 1 (use -v to see invocatio= n) *** [clang.full] Error code 1 make[4]: stopped in /usr/freebsd-src/usr.bin/clang/clang 1 error The failure occurs many minutes after the log entry appears.=20 No errors on the console, swap tops near half a gig. The=20 stable/12 sources being compiled were obtained via git. The=20 -current sources used to compile the running system were=20 obtained using svnlite.=20 I don't recall seeing this much swap used before by armv7,=20 but that's the only notable oddity. =20 The stable/12 sources have been updated every day for the=20 past few in hopes the trouble might go away, the -current=20 sources seem to be updated as far as svnlite goes.=20 Any suggestions appreciated, thanks for reading bob prohaska From owner-freebsd-arm@freebsd.org Mon Dec 28 06:10:24 2020 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 CBA764D1AE9 for ; Mon, 28 Dec 2020 06:10:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4D46bg2HT4z4ktp for ; Mon, 28 Dec 2020 06:10:23 +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=1609135820; bh=GH6WgooNMb7SdPMxWGyhiNsYgBNE+h9F5gl+RHJInXr=; h=Subject:From:Date:To:From:Subject; b=KFEdXlSWdTDSBkW4QY7o94jg1B1ptTGKwtXXiCmJOAFRwBLbijaE3wmxwjN+5SAayHWSVggZHfVxUMg8V/CBmHWkzxYQ2FbF2OTjTRmtUzUI5kqg6SBt8RLlStHvkQ5JAFbWBataaA9vgCfcuvuuk2XmZAXa5upEWAeBPcrzMz9AMOMGG9xCwSyDyjduBV0LmM200YWuFrB5ApuVFUYncbKsbatPgFFeypR57NjmZk6qJFPSvbRVsDTrjtot7MaeVraMBnCEMKtbEFkzr1FKgyMO+audM3CjYH8kwPdtQGrW4GoA7Ni0iIZ600P3HMGGBwAlIncb7LM+RTdEZYO3CA== X-YMail-OSG: pmCGSoYVM1k7qnw4Ycy9oF6sWJglADnFGbwFrV4cvM.mp3Sc3KxXQr01fCVQIxZ MwsLimvLyrojEKveKSNMv2DOVGDol2qwZER_eCbpxXjfj5LHdXTvPYGi4gTav6__TtyGfAfDM74z uOIRssoA_dkRMswVrccaGPdhEuHMt1HWU3EcKhJvGv_Sq2TFEVLQZ1X2JUGqoSM8lQtd58otj4O8 ClLFlY1H4jHkxEIl5xeShiyj8mojMJWHIhfAgdAecNBKsSr.A6z82cR0.4cY2yg1xHhU4ENegb72 KRVf3JLZDTxtqWeb4Pl_qJ4Y9fWypb4NdmLNsM0pcS.BI43lB43uyU6Iv1OZBHNyYi.t7iYOd.Em KRe19oFmd80BrGTkZvE9IyQmssvYXRrZq7BJWzXL947TvD_61RuNiJgaqhRvNGqvZF3LjH9sUinG KWjMUFgI4FbEXMQ.xpD0QEF47A07IlZ6pfH_UEDCaQX3viWp2U5.NK43z_7UWkL2Xu3kdygumIQK BWPUPy0ExTQSLGomSAo1o5v4qEr0vCHSqTMBJYisIVrWsdgZYIQAyOm4SQPA7tsR.I6tp92U9v1r Ydg4iYMCLiyfmrnqxXwvqcIw2dp1Jcm4.tQ5D5qfwev2SK5kFRD_cExl.6lbuPUWmBLcO5yQaSAL MKSxN3DiTo16bRHQOV4xZm8X0zow7gSC.zytNbHzUCZToSppbYp_R83z.qPrZa5pWvMVCCYxAb5n FYaWt8dCjyvbmSyQ0jIVbQP7jPTG35rvDxHCK95USS37Xi8HkLIK2BXIlV9YmZJuF1Gb8qxZCAXh NfjxiUb_IGU39U4VmUWYo5vUvHN72PFnpM1upDSTWRysjn6F6XIRgTMZnQpKJVmRM7eAzTaHaxQh 1yOklJnMVYw_rPTWQT_.cJ.6.BCAIhHEUT4mwV4y3yX9eydmSSru8cl4ZAtONmq3TKpd5wXEdO91 JLY5YeyRaXbpALYE1ULjr8_HHDnqIUvWv16bFKO7ItamKImBOyyHafqF7ipbo7gBK1ZrXiMeL8Sr l.MiKFc.25zPKbMuhG02LtU.MaGOhG8iwnHIxRAgtCHW9rF2y7sLplVDwmm9JEfGrGlWLq2PvQP2 xk8W9lkvp08YxDKXDW3Wo99q0bf2f31v6R.aRM4ILMIK2dVBor_1gS8.MKd4c7Y22V3NgeSiMzsd r_w8MfjZAQ5vsiyD79ovctvc2ksY02WJ8W1pGrH2HpNDj6auPX2uzTM5Y6M3fftcieWzDdnJRbYk oZcJeqVaaTQWE.8jRczyH1k5jqB.P4gaAmiX2DCjSkCrCDq0Ts9vNCvM2tM5zkfheFR0UP8Rgzwj l.cGGiFdfF8TYfn16eGbqfXuJN_iVnrrcGGSQ3tOlw3Y1ueUpuuVtjnjOK8nWWc0Nqc21WRMJJz1 FKEqL9nSYKwIv6uXZ1P85lnzgRatVfsOPsCbBbUR_MD_3VmHHJWaoYweaBRcTcIKO2k5wcxGeiRW 3VQ1iNuT.3s_BcRPZj0C1nOutEH3I0KKSYrdrmMiJKs5r5T5SnEpCzSmh5TEOh5V1ZNgigyUt1zk DI_e5eloMVRLQ08dG9rDeF2qc_kRXguf3x1T91dIZaBNqauQyp3DG.SNjBVilacPgLz7qYFClpkd ktZdUsLQyZprpCW9KqfCHFc0syoDww6bff3igTkc8iFgYWK3CFTFVmnd_SBoqGh5AgnhUgT9Lb5I KIzxgrMsa6_NtBD8bs3EIOaebgTp1FcH.Qy9litgeF3ThW.7E8d_l_iIgR12MH2NN0Pr7pzPIaIK .pcD79zLAYHtNafJA8VdS8GQF1MrThiL3M.MEQyuNok38_6hm2ou_Pe_AgjW36oEsPK0ZyLFgD.7 yGeoP1Ba12mzzgmgxf241VuwT5nrMoZIysBITQyKUBFd3fVjIMFUZznNYkR.J91.kQ0NU_SlBMLe 6_lWfgsMdqwS4PtY_t1iUDk6a6HYLhfA.gfBjye2Z1FVEsu_ibQE0pyEqW6C7BsQHx_cUngyP7xI P3HzsU6t30frFXPqKdgnTu8Zle1PCGN8X83IINgom005pL3z0SjAxao9bYHNVlGLvtRlqZ.UJR8u JGe42v8mCksgh8Zd617HoRsbDzgjjGhFtLDIlrUkzkXUMCNIJblcHgGZENfpC77RTVbYXBi3gc5g sGqhL_nL.Pabdw36yo.jh76LSELB4i9EXPv5IruIEsZtASQjt0r09IjxEvtFYJNaNrSRJ8B_zHM. _sEJ3yEVbvx04_DXGSKtGXUqcFeVi6AX2w7JJ4WOv2Gb.NkTxSo1fs85kGZnocZA5lIiW4RF9r5O iPO6hvWSKGMmoM5JrS3fMIt9ZzJo_ZPy3L0WR7zS__nCK0LAT9LDT5_nHyOEl1fEHgnQH8Xr8x1P 94h3yUoToS5z34uyM6OYo9DFTvN.gPQ.Pqo350wkMFE1JcgzsFYDSmQLdbOW8YCU97ePqeSBdPBN UAWUqK7T09u3bZkHdpJGxBrIFqYkotopkk2Gpj2hOg7.L7c1cb8wgf0TIQgA3kNfTDRNyvIiCt1I nxpr8CQ5XFemj9GtLJQsmUIuo9khe Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 28 Dec 2020 06:10:20 +0000 Received: by smtp425.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3fd931de8ae1fc2bad7f3bace5ee0501; Mon, 28 Dec 2020 06:10:19 +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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <20201228044840.GA28380@www.zefox.net> Date: Sun, 27 Dec 2020 22:10:18 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201228044840.GA28380@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D46bg2HT4z4ktp X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; 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.146: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.146:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146: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, 28 Dec 2020 06:10:24 -0000 On 2020-Dec-27, at 20:48, bob prohaska wrote: > Having a bit of trouble migrating to stable/12 from 13.0-CURRENT=20 > FreeBSD 13.0-CURRENT #3 r368820: Sat Dec 26 19:01:50 PST 2020 =20 > bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC-MMCCAM arm >=20 > This is on a Pi2B v1.1 The MMCCAM kernel option was added for sake=20 > of the experiment and hasn't, up to now, been accompanied by any > visible problems. World and kernel have been built many times, no > problems.=20 >=20 > Buildworld keeps stopping at > --- clang.full --- > c++ -O -pipe -fno-common -mlong-calls = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libclang = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm = -I/usr/freebsd-src/contrib/llvm-project/clang/include = -I/usr/freebsd-src/lib/clang/include = -I/usr/freebsd-src/contrib/llvm-project/llvm/include = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -DHAVE_VCS_VERSION_INC -DNDEBUG = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv7-unknown-freebsd12.2-gnueabihf\" = -DLLVM_HOST_TRIPLE=3D\"armv7-unknown-freebsd12.2\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/freebsd-src/arm.armv7/tmp\" = -DLLVM_TARGET_ENABLE_ARM = -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeARMAsmParser = -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter = -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler = -DLLVM_NATIVE_TARGET=3DLLVMInitializeARMTarget = -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInfo = -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sections = -fdata-sections -gline-tables-only -Wno-for > mat-zero-length -Qunused-arguments = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/include = -fno-exceptions -fno-rtti -std=3Dc++14 -stdlib=3Dlibc++ = -Wno-c++11-extensions -Wl,--gc-sections -static = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/lib -o clang.full = cc1_main.o cc1as_main.o cc1gen_reproducer_main.o driver.o = /usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libclang/libcla= ng.a = /usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm/libllvm= .a -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libz -lz = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libexecinfo = -lexecinfo -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libelf = -lelf = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/ncurses/ncursesw = -lncursesw -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libthr = -lpthread -legacy > ld: error: failed to open clang.full: Cannot allocate memory > c++: error: linker command failed with exit code 1 (use -v to see = invocation) > *** [clang.full] Error code 1 >=20 > make[4]: stopped in /usr/freebsd-src/usr.bin/clang/clang > 1 error >=20 > The failure occurs many minutes after the log entry appears.=20 > No errors on the console, swap tops near half a gig. The=20 > stable/12 sources being compiled were obtained via git. The=20 > -current sources used to compile the running system were=20 > obtained using svnlite.=20 >=20 > I don't recall seeing this much swap used before by armv7,=20 > but that's the only notable oddity. =20 >=20 > The stable/12 sources have been updated every day for the=20 > past few in hopes the trouble might go away, the -current=20 > sources seem to be updated as far as svnlite goes.=20 >=20 > Any suggestions appreciated, thanks for reading >=20 I presume the historical system tuning for small memory systems from our past investigations and help that we got. You do not mention -j4 vs. -j1 or the like. I'm assuming -j1 has been tried. You have not said if you have adjusted the likes of: kern.maxswapzone or VM_SWZONE_SIZE_MAX or if you get the boot notices about the likes of: warning: total configured swap (??? pages) exceeds maximum recommended = amount (??? pages). Mistuning these could lead to RAM fragmentation issues as I understand. Since the allocation failure is reported by ld while it tries to produce clang.full , I wonder if you have used: LDFLAGS.lld+=3D -Wl,--no-threads in, say, /etc/make.conf ? If not, the llvm ld will try to use all 4 RPi2 v1.1 cores (via threads, not via processes) and, from what I've seen, will end up trying to use more RAM than when it runs single-threaded (main thread only). Of course, links then take longer to complete. (LLVM ld actually ends up up with 4+2 threads, counting the processes's main thread as well.) Except on the machines with plenty of RAM (by a large margin for the hardware-thread count), I use --no-threads for contexts where I can readily control such. (Ports do not use LDFLAGS.lld and gnu's linker does not tolerate --no-threads as a command line option. So "readily" is limited to buildkernel and buildworld .) =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 Dec 28 06:56:25 2020 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 3A0B54D2DAE for ; Mon, 28 Dec 2020 06:56:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.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 4D47cl3hQ4z4mXh for ; Mon, 28 Dec 2020 06:56:22 +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=1609138581; bh=6MdPa1XKxq+hq15nQINcVSz5CVUcRxuUxdc1N0fNKzX=; h=Subject:From:Date:To:From:Subject; b=sqaboXr2tFVBblTGGyAjc7leO50yXdvFncUU/ae5WLVzsTQ6f+4K4vVV+wWA2RHmZMIxEMVftMVCRywXCJIQ+dUN2f0jMGn07Y/9j1Lhz28+L/q2jkmFHBdBNc0Q5c1qNGugdEpC5qthWaAdRcKXgIrd03pcpa67CeJ1MgaoSmtMcwJlWwKJiRq6KroOFGO7bMsCDp8GtZ1jom2isRaJ1tJH7zYFGuUSp0sCgq9NUJECUPcFK24xKFBjQCmkHVqoRL6vw2hwSORYTh8u3zv/OTmTIFWlUBzWVau91Nu03ZifpWdQTBbNAM8eF7PgiyXSHdC3JDk0xGkytHS6LtdRZg== X-YMail-OSG: IXsf8S8VM1mkayLyeklR.VbqGwy9tAnTUDZFtOJgNzKfCdCk2Zj1TdVysk9IRCU hufZmxBINeJvhOYiEM4YNfPASdVYD6kHQa_fjybt.tYWXtno2xAaakHt0F2pDoWp.F5x.iKSG8ds Iuh7K5F7zPAxmsz9y9jaEXokuIkV5CNZ2fhT_Hucv8PS8s25eQtqMZb10PIug5AGglc4k07amAdZ PeH0T4Vds7YUM5hgLQfkUZ3tGGNLqi2pp6ALENzxXLvudNOv5l3G0a3wU1fXighIPataOAuRaQiO J6_hOmZKkJVGYvFkw0jOADT8u8MoD5cH1pq2h19q84QvlZZEka04o.tpBV_IUbp7JJlLe9xnGpaV .KkApiS9PEfasBlfi7VNrjKDjtXaWwaHPm88q1hemdBye1mNdrk9_64yqGJpaih0RsRL.rZeXkFV aIvvUCrgFsETNRZhvbmEZ6ZGn89CEMvuwB6ukHRmNQnYTbtBTpGqhJAagErrD2LJQtoOw4w.xMAC woDe_0gbF.XXaHGCT8XEtC_c7Ko4ed1XHTtOdXMZc1lQ9vnZT5maWYakAYnGPFbr.EbYUtRjuuGG LFVspsSBCWVQPCbiBYlqDGfTVOiF0vLF6P03VtFrXp0FJtGDBNvNlMDNAxKAlWh3ePJiQ7czvxSZ T0HQNb6lueDv9iQ2sha0JcZ50mhg_w6OuB6vhcOnhgC8sny19HIvT4V7bnCNcBP9OC7w4sonSjN8 cS4GtttC9F4EmimpcGIJBzpbuJEknY4fmjTn1cXomCuLpCzbvPOmxUOgsXunu9QHJ_fnmgP5LcnN Gy9_IzrRQZ_qgB5IuzvwMhhNr_ml.irW6UnWupi_2L.pnY7dsVQObZx1r_nV5bn1wlYDwqW0cYtF l31RUErHTOhiop9YKL.SsEy9YGimiX3PCZSEFYWYNAJNkP9Q4dIRyqKhj8c55Tfnsr2X9hDaJ3Nb nJWRe5HnPx.vz5zlZRHCanaafBsMiaEdzxU10SSyztWhIA1Bty6n5xF6iHaaghzsIRpZvnQaOBPz qKn.bYmKdhYq1avVCwcPxdTR0fpxXhbsXYhKUiptKRmp8327o8VQzFK82ydmn3BQsDUQwgDFj6jl ThPRquOW.8SUta8P4rV7ttjX2B0wz6IqNXXre2S7WYbHViMCFAfwxI.jm9_PhP6sQVudUUiI9K8b iyslyN3.tH6i6D_c8FrCHA1ggLh4Ky.Lkw02bVaOJ0kuUG3Vw_gre0INUNvoKUlTgsOSK0PybQpQ Yoeatd0juNc_TqO7xOKLFO6hY6M4laQhBRk1_8GrhmX4HY3GL9x3oZuQ21S4VvT.QmNCL8P4E2L7 D9Br99IyX36xZP35J7el6ZFjWKbGZmIqnhlu3L68rbxi6WgDfn6pzNTBjQ6hqlObAGd_.P2QweOf 4sSHG5AbP.82PRPSRz3dimXC.34oWlfsS6ozpmlTmBNuLJ06qf3LHjGh0CxgwSjt_kJ7ooTBTx.I njlCqs7B0tvMnY5TvjT7bYiKZ2UpOCQpUlc6HVjIwYH7HXa..1V1IXOhkqfxlgBc6CQFW8loPzH5 H8uqu0Brg2EwP9lPv1jy2Uqb_QTk5ThvYAxkfS1_tR61XKFVxZnenzVX9wzOBDhxHX9ikZhDciEE hVHQBRIdWfTytdFk7H_brJ7IxEADOZNEqkq52WHA2xlsGCRN1OIkzLHbtpmfOoOpMaDE0V6viXax L36C9qMjFIMsTSvwkJ3C4HKPfaof0M2gMpgU0FeVHopquH5KQ7Jik9BjdU5pxauDABovNuho6CFv oqIE2JkRbPKi_b.u3cCl0vOa6XLS3h.eO8bPlCXbzNZM513BtV8WlG1UFGM_ePFQ1iCUWHBbG4qx oER4HMQ5xd_LlELkdlBNORwbDKWum24CrrnAb8ovp4sa36Dig8dpW9XNDHozrYxQ4s_Aslyolc.y QEhZ.zjMwl27cxnm3lhJyeWIq_yu28LT82GE3u3u4leNU9ZV_63BrFjjE5Op1Bz4Dy6RC_bfEGJy tVN2Lp55xBERhZn30NzsdlMXS3iCu_xrvKrX0UsI9NBSTLZDMBnSE0AO7fZoDIDMSFxIhFewXIFU sEmCOwMehiqz9KMYEt1Jsk8JeTzvlt2qQfReRfemPUtQTwWBUl.FyBgoWslIKc6KqZlFcjUEmVlx 3LBzsCgIyTfYjGJdM8gdW1wMYAYwBgNiEz8UeMPmlGCyy5Ab4I4FYSPzA_PdCz8jMQdOfJ8SbgwN BOoM9yr9VRmgVrh4cpQuklUV2AGPIk_Ywv.KfVMytD3eazXUzhPLAMwTSsRRzrTgPmZUyT_mmF8X JWSEDbgKUARStVB7UpDynwGvmTOsWA2lvYGCI4WrfO7Wl95mNkA0tVgZBnkwDIz_wJ3bVBEFPLTq K3Er6SNUZoiWK3V5n4L4RBQ6Cslj6ReXDazffWK71UcCk1B0aon47udHSdA0ckShwo82c138yXhd lzDiPEkzEwX5N4y8GsHfiqUNiR569xZIBBfJUcKt7eOfai94AQav1yE7H.CWnf57HZdbjhzyU7pA B4NNT448f3_vzg.rLfKk8_pgd2LM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 28 Dec 2020 06:56:21 +0000 Received: by smtp423.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d794e8c26863a234954cb9a7dffc7c12; Mon, 28 Dec 2020 06:56:15 +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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: Date: Sun, 27 Dec 2020 22:56:13 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201228044840.GA28380@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D47cl3hQ4z4mXh X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; 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.69.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.69.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.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: Mon, 28 Dec 2020 06:56:25 -0000 On 2020-Dec-27, at 22:10, Mark Millard wrote: > On 2020-Dec-27, at 20:48, bob prohaska wrote: >=20 >> Having a bit of trouble migrating to stable/12 from 13.0-CURRENT=20 >> FreeBSD 13.0-CURRENT #3 r368820: Sat Dec 26 19:01:50 PST 2020 =20 >> bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC-MMCCAM arm >>=20 >> This is on a Pi2B v1.1 The MMCCAM kernel option was added for sake=20 >> of the experiment and hasn't, up to now, been accompanied by any >> visible problems. World and kernel have been built many times, no >> problems.=20 >>=20 >> Buildworld keeps stopping at >> --- clang.full --- >> c++ -O -pipe -fno-common -mlong-calls = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libclang = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm = -I/usr/freebsd-src/contrib/llvm-project/clang/include = -I/usr/freebsd-src/lib/clang/include = -I/usr/freebsd-src/contrib/llvm-project/llvm/include = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -DHAVE_VCS_VERSION_INC -DNDEBUG = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv7-unknown-freebsd12.2-gnueabihf\" = -DLLVM_HOST_TRIPLE=3D\"armv7-unknown-freebsd12.2\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/freebsd-src/arm.armv7/tmp\" = -DLLVM_TARGET_ENABLE_ARM = -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeARMAsmParser = -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter = -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler = -DLLVM_NATIVE_TARGET=3DLLVMInitializeARMTarget = -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInfo = -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sections = -fdata-sections -gline-tables-only -Wno-for >> mat-zero-length -Qunused-arguments = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/include = -fno-exceptions -fno-rtti -std=3Dc++14 -stdlib=3Dlibc++ = -Wno-c++11-extensions -Wl,--gc-sections -static = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/lib -o clang.full = cc1_main.o cc1as_main.o cc1gen_reproducer_main.o driver.o = /usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libclang/libcla= ng.a = /usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm/libllvm= .a -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libz -lz = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libexecinfo = -lexecinfo -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libelf = -lelf = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/ncurses/ncursesw = -lncursesw -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libthr = -lpthread -legacy >> ld: error: failed to open clang.full: Cannot allocate memory >> c++: error: linker command failed with exit code 1 (use -v to see = invocation) >> *** [clang.full] Error code 1 >>=20 >> make[4]: stopped in /usr/freebsd-src/usr.bin/clang/clang >> 1 error >>=20 >> The failure occurs many minutes after the log entry appears.=20 >> No errors on the console, swap tops near half a gig. The=20 >> stable/12 sources being compiled were obtained via git. The=20 >> -current sources used to compile the running system were=20 >> obtained using svnlite.=20 >>=20 >> I don't recall seeing this much swap used before by armv7,=20 >> but that's the only notable oddity. =20 >>=20 >> The stable/12 sources have been updated every day for the=20 >> past few in hopes the trouble might go away, the -current=20 >> sources seem to be updated as far as svnlite goes.=20 >>=20 >> Any suggestions appreciated, thanks for reading >>=20 >=20 > I presume the historical system tuning for small memory systems > from our past investigations and help that we got. >=20 > You do not mention -j4 vs. -j1 or the like. I'm assuming -j1 has > been tried. >=20 > You have not said if you have adjusted the likes of: > kern.maxswapzone or VM_SWZONE_SIZE_MAX or if you get the boot > notices about the likes of: >=20 > warning: total configured swap (??? pages) exceeds maximum recommended = amount (??? pages). >=20 > Mistuning these could lead to RAM fragmentation issues as I > understand. >=20 > Since the allocation failure is reported by ld while it tries to > produce clang.full , I wonder if you have used: >=20 > LDFLAGS.lld+=3D -Wl,--no-threads >=20 > in, say, /etc/make.conf ? If not, the llvm ld will try to use > all 4 RPi2 v1.1 cores (via threads, not via processes) and, from > what I've seen, will end up trying to use more RAM than when it > runs single-threaded (main thread only). Of course, links then > take longer to complete. (LLVM ld actually ends up up with 4+2 > threads, counting the processes's main thread as well.) >=20 > Except on the machines with plenty of RAM (by a large margin for > the hardware-thread count), I use --no-threads for contexts where > I can readily control such. >=20 > (Ports do not use LDFLAGS.lld and gnu's linker does not tolerate > --no-threads as a command line option. So "readily" is limited to > buildkernel and buildworld .) Another type of thing that you have not mentioned: non-debug vs. debug status of various things (debug usually meaning more RAM ends up in use during builds). But I've not experimented to know if some of these could make a nontrivial difference in the RAM use. Is the host 13 built with debug information and debug code generally? kernel? world? Is its llvm toolchain build with debug asserts and the like? Is the clang.full being built one that was built with debug information? Debug asserts? Similar types of questions for the stable/12 "cross" toolchain (older llvm vintage?) if such is built and used. In stable/12 there are (for /etc/src.conf use): WITHOUT_ASSERT_DEBUG Set to compile programs and libraries without the assert(3) checks. and: WITH_LLVM_ASSERTIONS Set to enable debugging assertions in LLVM. and: WITHOUT_MALLOC_PRODUCTION Set to enable assertions and statistics gathering in = malloc(3). It also defaults the A and J runtime options to on. So using WITHOUT_ASSERT_DEBUG=3D but not using the other two would be appropriate for having less RAM use. But, be warned, 13 is still at a stage where it has reversed two of the orientations (default vs. what it can be changed to): WITHOUT_LLVM_ASSERTIONS Set to disable debugging assertions in LLVM. WITH_MALLOC_PRODUCTION Set to disable assertions and statistics gathering in = malloc(3). It also defaults the A and J runtime options to off. So care in handling src.conf is required if you have been explicit about those last two in past build activity. The combination for minimizing RAM use from these is: WITHOUT_ASSERT_DEBUG=3D WITHOUT_LLVM_ASSERTIONS=3D WITH_MALLOC_PRODUCTION=3D If I understand right, both stable/12 and 13 will tolerate listing those 3 in /etc/src.conf . (Despite the src.conf man pages not saying so.) There are, of course, other tradeoffs involved in minimizing RAM use (host live use generally and target output-files related) for what these options control. For 13's kernel options: what of the status of (shown disabled) . . . nooptions DEADLKRES # the deadlock resolver nooptions INVARIANTS # 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 DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones and possibly the status of (shown not enabled): #makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols and ( in, say, /etc/src.conf ): WITH_DEBUG_FILES=3D (if the DEBUG=3D-g was used in makeoptions). (Avoiding debug information being in the loaded kernel files helps avoid as much RAM use, for example.) =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 Dec 28 18:56:26 2020 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 107904BDF84 for ; Mon, 28 Dec 2020 18:56:26 +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 4D4RbX5jSvz4ZVZ for ; Mon, 28 Dec 2020 18:56:24 +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 0BSIuM3d035433 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 28 Dec 2020 10:56:23 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 0BSIuMre035432; Mon, 28 Dec 2020 10:56:22 -0800 (PST) (envelope-from fbsd) Date: Mon, 28 Dec 2020 10:56:22 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm , bob prohaska Subject: Re: Migrating from -current to stable/12 on RPI2B (ARMv7) Message-ID: <20201228185622.GB28380@www.zefox.net> References: <20201228044840.GA28380@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Rspamd-Queue-Id: 4D4RbX5jSvz4ZVZ 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)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(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: Mon, 28 Dec 2020 18:56:26 -0000 On Sun, Dec 27, 2020 at 10:10:18PM -0800, Mark Millard wrote: >=20 >=20 > On 2020-Dec-27, at 20:48, bob prohaska wrote: >=20 > > Having a bit of trouble migrating to stable/12 from 13.0-CURRENT=20 > > FreeBSD 13.0-CURRENT #3 r368820: Sat Dec 26 19:01:50 PST 2020 =20 > > bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC-MMCCAM arm > >=20 > > This is on a Pi2B v1.1 The MMCCAM kernel option was added for sake=20 > > of the experiment and hasn't, up to now, been accompanied by any > > visible problems. World and kernel have been built many times, no > > problems.=20 > >=20 > > Buildworld keeps stopping at > > --- clang.full --- > > c++ -O -pipe -fno-common -mlong-calls -I/usr/obj/usr/freebsd-src/arm.ar= mv7/tmp/obj-tools/lib/clang/libclang -I/usr/obj/usr/freebsd-src/arm.armv7/t= mp/obj-tools/lib/clang/libllvm -I/usr/freebsd-src/contrib/llvm-project/clan= g/include -I/usr/freebsd-src/lib/clang/include -I/usr/freebsd-src/contrib/l= lvm-project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D= __STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DNDEBUG -DLLVM_DEFAULT_TARGET_T= RIPLE=3D\"armv7-unknown-freebsd12.2-gnueabihf\" -DLLVM_HOST_TRIPLE=3D\"armv= 7-unknown-freebsd12.2\" -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/freebsd-src/arm.= armv7/tmp\" -DLLVM_TARGET_ENABLE_ARM -DLLVM_NATIVE_ASMPARSER=3DLLVMInitiali= zeARMAsmParser -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter -DLLV= M_NATIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler -DLLVM_NATIVE_TARGET= =3DLLVMInitializeARMTarget -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTarg= etInfo -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sectio= ns -fdata-sections -gline-tables-only -Wno-for > > mat-zero-length -Qunused-arguments -I/usr/obj/usr/freebsd-src/arm.armv7= /tmp/legacy/usr/include -fno-exceptions -fno-rtti -std=3Dc++14 -stdlib=3Dli= bc++ -Wno-c++11-extensions -Wl,--gc-sections -static -L/usr/obj/usr/freeb= sd-src/arm.armv7/tmp/legacy/usr/lib -o clang.full cc1_main.o cc1as_main.o = cc1gen_reproducer_main.o driver.o /usr/obj/usr/freebsd-src/arm.armv7/tmp/ob= j-tools/lib/clang/libclang/libclang.a /usr/obj/usr/freebsd-src/arm.armv7/tm= p/obj-tools/lib/clang/libllvm/libllvm.a -L/usr/obj/usr/freebsd-src/arm.armv= 7/tmp/obj-tools/lib/libz -lz -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-t= ools/lib/libexecinfo -lexecinfo -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/ob= j-tools/lib/libelf -lelf -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools= /lib/ncurses/ncursesw -lncursesw -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/o= bj-tools/lib/libthr -lpthread -legacy > > ld: error: failed to open clang.full: Cannot allocate memory > > c++: error: linker command failed with exit code 1 (use -v to see invoc= ation) > > *** [clang.full] Error code 1 > >=20 > > make[4]: stopped in /usr/freebsd-src/usr.bin/clang/clang > > 1 error > >=20 > > The failure occurs many minutes after the log entry appears.=20 > > No errors on the console, swap tops near half a gig. The=20 > > stable/12 sources being compiled were obtained via git. The=20 > > -current sources used to compile the running system were=20 > > obtained using svnlite.=20 > >=20 > > I don't recall seeing this much swap used before by armv7,=20 > > but that's the only notable oddity. =20 > >=20 > > The stable/12 sources have been updated every day for the=20 > > past few in hopes the trouble might go away, the -current=20 > > sources seem to be updated as far as svnlite goes.=20 > >=20 > > Any suggestions appreciated, thanks for reading > >=20 >=20 > I presume the historical system tuning for small memory systems > from our past investigations and help that we got. >=20 Correct. /boot/loader.conf contains=20 vm.pageout_oom_seq=3D"4096" vm.pfault_oom_attempts=3D"-1" > You do not mention -j4 vs. -j1 or the like. I'm assuming -j1 has > been tried. >=20 j values of 4, 2 and 1 have been tried, to no effect > You have not said if you have adjusted the likes of: > kern.maxswapzone or VM_SWZONE_SIZE_MAX or if you get the boot > notices about the likes of: >=20 > warning: total configured swap (??? pages) exceeds maximum recommended am= ount (??? pages). >=20 > Mistuning these could lead to RAM fragmentation issues as I > understand. > Dmesg reports=20 warning: total configured swap (579552 pages) exceeds maximum recomm ended amount (467936 pages). warning: increase kern.maxswzone or reduce amount of swap. but that hasn't caused recognizable trouble up to now. Adding even more swap doesn't make things any worse.=20 =20 > Since the allocation failure is reported by ld while it tries to > produce clang.full , I wonder if you have used: >=20 > LDFLAGS.lld+=3D -Wl,--no-threads >=20 > in, say, /etc/make.conf ? If not, the llvm ld will try to use > all 4 RPi2 v1.1 cores (via threads, not via processes) and, from > what I've seen, will end up trying to use more RAM than when it > runs single-threaded (main thread only). Of course, links then > take longer to complete. (LLVM ld actually ends up up with 4+2 > threads, counting the processes's main thread as well.) >=20 > Except on the machines with plenty of RAM (by a large margin for > the hardware-thread count), I use --no-threads for contexts where > I can readily control such. >=20 > (Ports do not use LDFLAGS.lld and gnu's linker does not tolerate > --no-threads as a command line option. So "readily" is limited to > buildkernel and buildworld .) > I didn't know about LDFLAGS, but a re-try with=20 -j1 and LDFLAGS.lld+=3D -Wl,--threads=3D1 (apparently the syntax changed) in /etc/make.conf=20 promptly reproduced the error.=20 At this point the host has two source directories: /usr/src, obtained using svnlite, holding -current and owned by root, along with=20 /usr/freebsd-src, obtained using git, holding -stable/12=20 owned by bob (member of wheel) where the error is occuring. Could this be either a permissions problem or a conflict among intermediate files left over between make attempts? Each source directory is matched by its own object directory, so that seems unlikely. There have been no warnings on the=20 console related to memory or swap, only the cryptic little=20 "cannot allocate memory" in the buildworld log. It's especially puzzling that the problem is evident only when compiling stable/12 as a regular user, but not when compiling -current as root. I'm trying a sanity check now by deleting clang.full from /usr/obj/usr/src (two copies) and restarting buildword with -j4 and no LDFLAGS to verify the error isn't present in -current. That might take a day or two.=20 Many thanks for readying and replying! bob prohaska From owner-freebsd-arm@freebsd.org Mon Dec 28 20:07:42 2020 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 D5A344BFB8B for ; Mon, 28 Dec 2020 20:07:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.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 4D4T9n5pZkz4f7Z for ; Mon, 28 Dec 2020 20:07:41 +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=1609186060; bh=M0pPto+dzpwwupFr9cHTrj+S7tqxElpauFy/BPoKGIG=; h=Subject:From:Date:To:From:Subject; b=oxv5bl0auM2IvsS1B04KMrakiXqSL3vnEfjGV1MZV9NqOEmGik6+LeYCX7EzO+UIQjcM0vJpFeTx+h+6fiAoKwJkjTftcOkqX52S4ds1W7GRgZ+hB+he6706ttn79rVpmG5ffUtTklLcy6QX8HA0fzD3yfFBQjYXlY6MnQSJ2u5QvNGxiseVw/rbkIwKqucMap0HlGTUNbq58/AV6SpdQqGFwjVCzAhnlh4VdnLMtWzXt/dtoZk4kI5IDCfQgM7HfbPn6+6cEPdW2pqWoQibP66vjD5ykqGcGf7aoHrdyx7Qbr0Vrdo2fss6kLr8b9RXObJ2S2sC/gV7ITd2ZqFOKA== X-YMail-OSG: LfW0IaoVM1mG6BF.w96CsSDn4blxjlLhGCUbaLJWvyOCrs9AnIDBswMYBwdnmbf yxS1yWHQoTMoxpwIGx21DBoM8QfOHiXWn86Jw2x9xu_8GFH2_S_b6m3gq5Asm6accG9LWWnzJV68 lutNN5SkcO3dH.nGXXo8ItlJDQeNKrb._0lC43GG53cvboHbhcjPB8l8HWM6ki25Q07vzU0ekwlR E5m1Vxj7VkbuoN2Hydzn4YN3xEoMvAr9.2Y4BrVEb4KkpmzUG3VJM8lw8kVP55cA_ZG2SyLKTk3i TShstu3j_Hbffzp0BKUM.46VOpknO2ghB1P86ecvjBHRZ2wGbg1XpCZXtIihbYluYXva90XXnY9. _lPQACuxajZSeYEB9ASPNP_4dmUOGKRfCmricoVTHgly.MJId66Rrwy5EatbI_SbGQaQNxTPGB79 vVSgRAEwfwPhjX1HjABgJqubVlLdlil8Eb1Ib3hFy_QFBe4mlHePN9A6FwKFkaN_7W5Zr4AOuv3f kLakMIUGl7xRpAzvY1qwaBC1Ue_nVnfp91DSB_Dw3gTXUP5zIEtCPB5REicewvm97fMP7kkEtYxw 4gKW6z5gMbVpMOS9J8BK3BCwnHdC3po7ACeLh5HdBuXkBxDY1xOPXsNDy585hecYjO5.GgyDy01u .Ctbvey2wNPgoPW3SLUtI0JlkB2hNWx7EvEwfXnpYNJCZfoK8aavTYIwA3wIqqiA2y_aBsGp5ipH ztcSENvY12lTm4u9Ax0RUQpMkdbZfyVXT71pP7.dLxo.CQJZKxw9f.VUGWQ.4IYAZjRD6lx6VjIW xDHmBkPldOLdUTCeiyLRcve6I3HfaMrgBPsprbDpNAIBbnErQIl8FESEt_G.aX7NWq54yJyS9zyp 5_wpmkHslmHL72dSecl2hghwB.LShPEwLz.VIKA9MdmPDaNxY3kMJoqdwInlJgaNlkMPOGpd1bv1 LECMQ8Txe50Owhwz50VXCgjklvBDgGYbQtqnSz99n90VLq42q5ieeJLyXnsej4FUPY25s12LkPtV MZWJW9j29C2.o_h16iYoNyDkSn2c2ypeEfsZbqtfae.GFnhx_5SMxoZSm1O9uwaY72TXv4jNC3Hj EgxLlz_scZWnGkn44sJ26e2lhzh73Hrir4MO9.K_KGbGYUR0HDiswSwj2YGHGWYlvZUf7vJSiwoh xuNmO4hY8NMuDcsusrP1gZJCKhp0m9PoCHNJ8qpSRhYSHmY0sTOWwk8TgGAnqf5fsgixgxHWaLDj DiL7gk13Z.bT5lm7PY8d8i2ez_nGhcgf7ZdD4_7s8QuhcsFuKHdfes6dYzJ2SVYhUb64Nmhzy8nt kwJzD2pzLQIgU8ZemRT7f_B7elfP2hJ6akREgeCIdLaQh8vufxWAjJMbZhgR.i0uSrAAZdg4gZ2G JLXfrWcQPQCQ8GyJgw0IgKGICpt3cikstWEEQMt.7tJRaSGiYPpLY_.N57jMkAnJeeZkjQF.9Mzv SqYV3L_ZEdM59HTpp3La91l2lgWQ2uj0qPHvTpcmAXNX9syJFGV218kQIaW1D5OUib_.p.nQA5Wq Ak33PVMebexGnAqbjond5ZDmCxe4vUVXOluR29Ekn6A_uI2djLpfoXF0zugUdf9jmUkkBszGz.uk wOtI7EWCr_awHTXC6v1dvzqFRpJug8uwXDeLiGx9SPUPgzNUh7OBluLFCvEfaDXrI2CxXU1TO4wn c52BOfHHGHgab.rm.wnp_7jN2wA5SaqjimRXV.JWSnzM0ti3Toxex7PXdvlj1eozCMn8abCGQd_j Tgcj3B6ZzoH3whL427yx7lNPRdXypQBabAzJDwrRSDJCVveftwf8HiRUoRYr6kEDnrxCVnrNsEJn YqGrYyKPgLTI8rRaHnIqCWDxVLv6n.Dtih2kuAxS_2gLMeKXYc7s1w9bjCmjhv9_l0uxbtilK096 jnrZQfi_7WsFUkH6Wqraorya26aHMq9kwvXuAfCeDi8cijn84.dFeItehURhsDrLCp_E0V891w45 dPe0HgfKcDePMBAdJ1_m_J_M6.L8iTOuW4D8ZxjfyeXzEelZxNmCeNLQuSSurraypwptM6WOWxnA _.788ARfso8NxUJ29dmpO0zM5em5BDp1Xizy1l091Jiz8Z0sS2FFeRY6OBgOl.KRcXagFyx58yCB fKKj1zD2QGPaejhU8qybUwSnMQ8IimOJt1ZePKr68zog97ZWt9v23BU3FQw5Y00p10iHMY8YhCUV BzJ..NrycZ7.2iqyJaa62hAX0BL9mHCVxjiW1oztg_nZi7E0UW.gGWcySbl_YxtUf4Hoqrxovx9B ojJ5w_IWis8KlG8f0boaWTBKDQjZZhuGfzWh3OH1HU4_VUr4oB1JRKW4rlTpEJtkxf4FjQXzVFTa O9qSNxnZ6LHNhUMnMx9NviKmcNJaAlLK6vUiI6xrv_RebaVPXszKorz4XPHWLzsoslQ5povYlOpd _wJ8Cv9MQgC2sb0qPAyPjyErQIYTLlQdAGFKyR43RYrVOqTor.Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 28 Dec 2020 20:07:40 +0000 Received: by smtp401.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 84f51e92301f390bdd3896bd12ae0415; Mon, 28 Dec 2020 20:07:37 +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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <20201228185622.GB28380@www.zefox.net> Date: Mon, 28 Dec 2020 12:07:36 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201228044840.GA28380@www.zefox.net> <20201228185622.GB28380@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D4T9n5pZkz4f7Z X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; 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.996]; 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.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.65.147:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.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: Mon, 28 Dec 2020 20:07:42 -0000 On 2020-Dec-28, at 10:56, bob prohaska wrote: > On Sun, Dec 27, 2020 at 10:10:18PM -0800, Mark Millard wrote: >>=20 >>=20 >> On 2020-Dec-27, at 20:48, bob prohaska wrote: >>=20 >>> Having a bit of trouble migrating to stable/12 from 13.0-CURRENT=20 >>> FreeBSD 13.0-CURRENT #3 r368820: Sat Dec 26 19:01:50 PST 2020 =20 >>> bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC-MMCCAM arm >>>=20 >>> This is on a Pi2B v1.1 The MMCCAM kernel option was added for sake=20= >>> of the experiment and hasn't, up to now, been accompanied by any >>> visible problems. World and kernel have been built many times, no >>> problems.=20 >>>=20 >>> Buildworld keeps stopping at >>> --- clang.full --- >>> c++ -O -pipe -fno-common -mlong-calls = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libclang = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm = -I/usr/freebsd-src/contrib/llvm-project/clang/include = -I/usr/freebsd-src/lib/clang/include = -I/usr/freebsd-src/contrib/llvm-project/llvm/include = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -DHAVE_VCS_VERSION_INC -DNDEBUG = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv7-unknown-freebsd12.2-gnueabihf\" = -DLLVM_HOST_TRIPLE=3D\"armv7-unknown-freebsd12.2\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/freebsd-src/arm.armv7/tmp\" = -DLLVM_TARGET_ENABLE_ARM = -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeARMAsmParser = -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter = -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler = -DLLVM_NATIVE_TARGET=3DLLVMInitializeARMTarget = -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInfo = -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sections = -fdata-sections -gline-tables-only -Wno-for >>> mat-zero-length -Qunused-arguments = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/include = -fno-exceptions -fno-rtti -std=3Dc++14 -stdlib=3Dlibc++ = -Wno-c++11-extensions -Wl,--gc-sections -static = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/lib -o clang.full = cc1_main.o cc1as_main.o cc1gen_reproducer_main.o driver.o = /usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libclang/libcla= ng.a = /usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm/libllvm= .a -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libz -lz = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libexecinfo = -lexecinfo -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libelf = -lelf = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/ncurses/ncursesw = -lncursesw -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libthr = -lpthread -legacy >>> ld: error: failed to open clang.full: Cannot allocate memory >>> c++: error: linker command failed with exit code 1 (use -v to see = invocation) >>> *** [clang.full] Error code 1 >>>=20 >>> make[4]: stopped in /usr/freebsd-src/usr.bin/clang/clang >>> 1 error >>>=20 >>> The failure occurs many minutes after the log entry appears.=20 >>> No errors on the console, swap tops near half a gig. The=20 >>> stable/12 sources being compiled were obtained via git. The=20 >>> -current sources used to compile the running system were=20 >>> obtained using svnlite.=20 >>>=20 >>> I don't recall seeing this much swap used before by armv7,=20 >>> but that's the only notable oddity. =20 >>>=20 >>> The stable/12 sources have been updated every day for the=20 >>> past few in hopes the trouble might go away, the -current=20 >>> sources seem to be updated as far as svnlite goes.=20 >>>=20 >>> Any suggestions appreciated, thanks for reading >>>=20 >>=20 >> I presume the historical system tuning for small memory systems >> from our past investigations and help that we got. >>=20 > Correct. /boot/loader.conf contains=20 > vm.pageout_oom_seq=3D"4096" > vm.pfault_oom_attempts=3D"-1" >=20 >=20 >> You do not mention -j4 vs. -j1 or the like. I'm assuming -j1 has >> been tried. >>=20 > j values of 4, 2 and 1 have been tried, to no effect >=20 >> You have not said if you have adjusted the likes of: >> kern.maxswapzone or VM_SWZONE_SIZE_MAX or if you get the boot >> notices about the likes of: >>=20 >> warning: total configured swap (??? pages) exceeds maximum = recommended amount (??? pages). >>=20 >> Mistuning these could lead to RAM fragmentation issues as I >> understand. >>=20 > Dmesg reports=20 > warning: total configured swap (579552 pages) exceeds maximum recomm > ended amount (467936 pages). > warning: increase kern.maxswzone or reduce amount of swap. > but that hasn't caused recognizable trouble up to now. Adding > even more swap doesn't make things any worse.=20 The question is more if having somewhat less than 467936 pages of swap leads to less problems with allocating possibly sizable contiguous RAM if such is being attempted. (It may not help.) >> Since the allocation failure is reported by ld while it tries to >> produce clang.full , I wonder if you have used: >>=20 >> LDFLAGS.lld+=3D -Wl,--no-threads >>=20 >> in, say, /etc/make.conf ? If not, the llvm ld will try to use >> all 4 RPi2 v1.1 cores (via threads, not via processes) and, from >> what I've seen, will end up trying to use more RAM than when it >> runs single-threaded (main thread only). Of course, links then >> take longer to complete. (LLVM ld actually ends up up with 4+2 >> threads, counting the processes's main thread as well.) >>=20 >> Except on the machines with plenty of RAM (by a large margin for >> the hardware-thread count), I use --no-threads for contexts where >> I can readily control such. >>=20 >> (Ports do not use LDFLAGS.lld and gnu's linker does not tolerate >> --no-threads as a command line option. So "readily" is limited to >> buildkernel and buildworld .) >>=20 > I didn't know about LDFLAGS, but a re-try with=20 > -j1 and LDFLAGS.lld+=3D -Wl,--threads=3D1 > (apparently the syntax changed) in /etc/make.conf=20 > promptly reproduced the error.=20 Hmm. It been a while since I did a native build instead of a cross build. The cross build context has RAM and does not use the assignment so I'd not noticed. Thanks for the report! > At this point the host has two source directories: > /usr/src, obtained using svnlite, holding -current > and owned by root, along with=20 > /usr/freebsd-src, obtained using git, holding -stable/12=20 > owned by bob (member of wheel) where the error is occuring. >=20 > Could this be either a permissions problem or a conflict > among intermediate files left over between make attempts? > Each source directory is matched by its own object directory, > so that seems unlikely. There have been no warnings on the=20 > console related to memory or swap, only the cryptic little=20 > "cannot allocate memory" in the buildworld log. >=20 > It's especially puzzling that the problem is evident only > when compiling stable/12 as a regular user, but not when > compiling -current as root. I've not experimented with regular-user based builds at all, just root based builds with the files own by root. Have you done regular-user based builds before? Is this new behavior for something that used to to work? > I'm trying a sanity check now by deleting clang.full from > /usr/obj/usr/src (two copies) and restarting buildword with > -j4 and no LDFLAGS to verify the error isn't present in > -current. That might take a day or two.=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 Dec 28 20:55:45 2020 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 967F84C1494 for ; Mon, 28 Dec 2020 20:55:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.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 4D4VFD1NNjz4jZ0 for ; Mon, 28 Dec 2020 20:55:43 +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=1609188940; bh=Wn0ZNVCizU1W98bh2xO2BPjlrrn18Hj4L3jt2+PE1dn=; h=Subject:From:Date:To:From:Subject; b=ZScy2KYiT6d4wJSMfR6GJBVniD6TQk9Eb3K1OAcbeRLcYP50cUpb90WcjvN34Hxv7f5KRbworMTiWO30lH2N7dHQNEQ9SEdLmGAzA252/gnjFEuTY6v8jCH7AcapV+TnOrSnK63rh3T6zi2sfiMiV1mpJiTX1zwTafmhqeFUvLSZ2SKtm67cqUq2+a+9gPziJ1O0o0RIfYEEGr4xfQQSIrIN55xJX2ivjzKT1gMJG3vSjMseMt/pKoPFKVdaVKo3ENPzdB2Ounk+NEzNntJbdTApdmMtwrSy5Igmsrz//xQ6Cv6s6tak0yF6B/2cRtsp9U0jb6I9jOLmbaG8Hmn83Q== X-YMail-OSG: HuDkDjMVM1mIbfP0mvi1NT25BQK6FADndbnQsGx.EihBvxdZYyXauFSfSA2PWQD JxndM.4xVetKg0T8b0b.TWNYYrwa.vFNCEIL.FpovuX3x4CoYCXDeqBQp2_RW_A1BqVgHVHbfWyG XJuGU.9NaGm1w7O7xT3lNdpeor0TA6S49YPwzs_qLUOKfmJm3F7jlq2WzTEYYYld8baOKVjL3I7X tZCPDhjHOEXe2KUWwQrfExpRpO8dKFbYQpNqcLUZJERgGqxd_O9.rJPmDoAVtT8KjmJf6npX6KjM Hzd7QDyOT5ENo36eQ7ihl9qmzLkgGjgD6bDkv4jMtoXGgCBgWRdKPX9uRKxerQ2JuXOPIztZBjm8 KMkinbtFuAKfOSt7uljqvYh3YYhkZDicZGRnjQigkbn0cokmzcHt88YcD1nK8v16h4OWf9i0aIy1 L_CCvYhcESqZ_RWr_SuWLCnpx7DFm0tNJlEgDiQ5LOG3Frtk4_nIG_h0Xxu_GGbN4bwKbSooXRbW SiSBl8ui3iLFgqvBzigWzWGXTvM1je_gyAcx4wunsZKQx6K4gBMwxj2wKGWYF8t0XB5dl0BnngCp y3WckD7k5QQd8Jyw_tHUL6wl4qGmXXkn5YS_wIedaGMsMoabqYyP36jr9ytHZrrbOWFcWWpbHV0X b2yQXGzy4Mf8ZN5JW_2EEQg2tAS1X960MB95.FLnpGwSMn65_T4ILTp4R61f3kHlHrt7E5z4M1Ft NvYa3jZgezjMEqJwi62Ubz6bK4yf.M7yLAhf32eYj._PvI2xKByw5RcqEsUuLFe0VGIGJ8W.5QWn 7tf5jM4VFrsWG_pHSK1isvRVbOxcJpJU_XMmFNWkj6MTYcFEiYEkckwKDR8Ol982S4yNfvhvuYzI Ht0S82amF_V25kk08s.UVzsLilsGg5LgGopw0C3oh9zKfgzb8s7WQAv8gtPV7owESMbLmMdrWTQg NmQbY2GUognVcJJXGUN_YOzPKjwj4yKnoHlsop0wQw47Et4QPjbxMslOuWRPGN3QNyMobm4As4Pd 4gJwRy8efS9HHzEervM._FNs4C.RnsJNK1DQrzzqr3qngzHvZb1dFLNdwqXsE2ZznAlR3mh41TDg tvelWmmFd733xt._lqNFIJw9H4Up2HDpA9J38CMN3VwF5rSs4Qcr90h3S9SyNr58XB.cA..YlDLa AQFzZ0lYXx3PX9ss_mJnAgNCP3E5EYu1DUl_gp1Lte4bxKNtq0xjElEneYRww3qJxRaZG_ZfahBE XbXLanDX80hD4vUoVp8P_QS0.ig6yoqYaQC3lEWT_gvgdQzsNkeVci.4hJHtBZHahELGyrvnL0Jp QEdFBXitcagQ4EkwinjMuwkcEYJLpeAz17ACQAN.IcnGH8j7snSDk29911sh1x7Vdx0klDzctaKv zFxF1DQnRprz0WWo.pg1hMHq54rrEbFAjKb6FnBVHjl4wRXBI41oM65Agam0CdZw0xCU6SCVIUSd 2GZ0qOOUfMEjTMU.kjX2urI0fiHiLSer_tWQqM80nehHbmZUbsW_SCTDRLA04BiQEph.oggYpW4U gllNIDjq.mZZN4OnOgiqWiVEIql7Uv8ztWmyodkoWd60N7dYx02udSH3M.pqEO2DlC7rkOAL64I. gYQSN5juIySq0LANSAg8OSjsMpZDAcCIkOBqmgZdk.lqRo_.kdYXqLd6BIcXv4Z4pDXZOBJd22aY LlFQ1uTDudlHi6Co1Q30Gh4p.cqdJgFvcOOFQAoAGVSQTZwyLPIsTF8VV1avRJD5uIJkNMp7Jw57 TRrc2QBylPbnqaTZYMifB1KJ.bFJmBhuMaVO.cPRizPkfI0AGq2KhkQCnKzr6AXmGrbDHwL8NZa2 rs1DRmVtW1XfVMRsuVwTUqWYb56UIhAVZYGV81UfcN1PznXplAZyn2C45Et7uaY6MOfi4ZOnpp1j 4hgc7a0wMmiSHLZDnwLa4baInC.hL7Rfpkxwqd2htJVqp7VaKL1InsfYQZu6ypxLJ55m92bHEY2q EbmZLGW0BMthhYVbxZ0nMslK8Ur3PDNTeNZlPtxTEO9oloCHz6e26.oBT57CLliuQroXxtzD_BEK 1inuTU3hsCiSTuiVTxuzRZUDDPRnvNbhGXY1.mJNWv_96nceaYGe.ieHEopdmCPgugG1iofoRY11 ldGZn33DzgtisBwXo9pRDeL_rI79aoXjJHMgpLosCibIHnCbANAG8SHp0s7pex3N5zoVX6FkzyBi ZEUQyVVmXqeXOSZ4GzfFmPnkoV2romHB9dthkohMKguOUsRlUtUpY9bYI_O0GRmh.ENxIpY3Ez7j 9hcVPKXAtMBf341iJNdfe.yBBPUu1S.Xw2fPbq5pndbGpSd6eUqiTOyeLa0GwSTwyBz2MJBM8iUw l.LlYqeWJdHTEzKam8LnYuMAvk.q7Bk2cLzPY3_tjAu03d0GjBLjpe6bhgMruw6GD4GH6lY2CH.j nVLNfI6_ULAiiS.JRLX7A3Iv6Cd0vFZ_zjJm96ZqV2XHmxT0gA1iRYJENM34Q8q5NP4GQNnEyUS9 wLQSC7sjV5d.4kJSO24sTw3OHsT6e Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 28 Dec 2020 20:55:40 +0000 Received: by smtp421.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b4db985014399ea39896a3398c57252a; Mon, 28 Dec 2020 20:55: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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: Date: Mon, 28 Dec 2020 12:55:34 -0800 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> References: <20201228044840.GA28380@www.zefox.net> <20201228185622.GB28380@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D4VFD1NNjz4jZ0 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; 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.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.64.31:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.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: Mon, 28 Dec 2020 20:55:45 -0000 On 2020-Dec-28, at 12:07, Mark Millard wrote: > On 2020-Dec-28, at 10:56, bob prohaska wrote: > >> On Sun, Dec 27, 2020 at 10:10:18PM -0800, Mark Millard wrote: >>> >>> >>> On 2020-Dec-27, at 20:48, bob prohaska wrote: >>> >>>> . . . >>> >> I didn't know about LDFLAGS, but a re-try with >> -j1 and LDFLAGS.lld+= -Wl,--threads=1 >> (apparently the syntax changed) in /etc/make.conf >> promptly reproduced the error. > > Hmm. It been a while since I did a native build instead of a > cross build. The cross build context has RAM and does not > use the assignment so I'd not noticed. > > Thanks for the report! lld for LLVM 10 always had --no-threads as I now understand and stable/12 still has/uses/needs LLVM 10.0.1 (with updates). That means that lld from LLVM 11 was in use (FreeBSD 13's system ld). The build was probably trying to build some LLVM 10.0.1 final+ materials for bootstrap style build use in later build stages (older FreeBSD targeting). It likely had not gotten to the stage of building freebsd stable/12 material itself. Attempting to build devel/llvm10 might well have the same issue without having to involve an extra FreeBSD source tree or build. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Dec 28 21:19:50 2020 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 7CD674C1D21 for ; Mon, 28 Dec 2020 21:19:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4D4Vn13pShz4l9q for ; Mon, 28 Dec 2020 21:19: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=1609190386; bh=spJKniod4KwpkqftfxqBuQYllu+I/7w+mLEYpCewyr5=; h=Subject:From:Date:To:From:Subject; b=seesRvXOn2itLovr856H1nlMAe9gUgY0a0G9gv9fl8nIYUxSbIeECoir/PqrRLvD6W8pJeXSnGy7mTVci5RfVG59eaPwvyo7w4q/FgtP+Mk3AKpWPns5Bl+ZnPySd1HL+DkV22thP1fnxlK6AK8y0d2tUVpT4MjXueaWH/7bcE+MOcoMZ3sXzoAJplP9lk4dwwGS7/EjXe+z8kRIe6Ppv0MD6+PAslRzb//Prdc36F8bR8bJn64j7INoGs+IhhM46knl34ymVM3H12MXy02EpBc8S/3N5sJX5CUBiEn1sm/RLvKE7MCVXkxP9FySFp6zRT4bZVi9ync6LbksaZ42qA== X-YMail-OSG: PwFcqRYVM1m5I7zbGjjK8QoTopVmVgSuErRwxLMFW1N20ZmD2VET9ET19rS3hYF qy8M44bVfm8aKRcfRKltl6DvF6Qlz6G3dzX_IlKOJ50Xp2CsIMsfnbLfB9EYBqNyrMATiy5lDQJY jdTpvwjG8lBWKXAL2._83RpzTobwS0MFCryYOF3kzFDYK8xKX9xdMC8I1ju.fhF1ywZmSaDKc8vu R7W6s.AgBfTZrMvlcCBgqwGCQN_44gG5BDE6fFKLMhQyhIaomHkhqB7L2eCcR27y9dYnRv6aO8QS nNWjj2EBnZjz147.pvnHWHE7v0G8DsCy.zDWGeFdDS5cdzp.S64HI8pkF1UAMFxRTU8TNkiDDkFT S6s44ODqcFElCmWXHVVHprC9vJEGQxJNFeHQZoEP7rO3HXNPs8LFKiUTx2MkLid_o9xqRgphI5iQ fNapv4vRvEYNj.9DYemvcZ4ks3Vsh4t2uqf7wvRDpnz30UrAiW_0TqD9FGhwI_7RtzbZj5VeTfTr A89UYE_qNVvs2tswICtiLKjKOJitmy8At.aYLOURypEjGUMIw4rH2oHW4WBZ73HMrNE7acBgixWh r5FxJJsNqVzrWwJ95CJsJYBx6LBtTchZJtfuWZRxDuegfe3wAMVyEhKCqdDu.bwODwRFvTQ87Qom iPeWXKksrzw9lC9wF5KyPljRRLJGoJ9py6BqOHn_CwTJoYtWwIonvEMj9SJRjEUrteDwNMzfN19j nMRgwAFzmC2s4enbCxeVPEtmCU2Rv4N2WnUCyRrEFEzM7ak3zP8SZVi0.V4ykj.E5uk7_Qq0fE7p LTDKIa7owmXA.lfl9p1aWnmN1SsKuZVJE5F6.1lHAHK7SspCBvwHdcPAkTN.MjLlFZ7TcmV3kClK Zu7GeXC_dHZ2RP3DJd2M94gPx5tXGGNkxNNwSJ.xJkzZUV8UKNlDDaJ5FZsaLALk2x5pIc6zGt4G 0wj3LlbRsBT0mzjpcAASVN4.v.w5ZsEMv9ILl8vFYK2aRTYY_WauPbmKx7H5tGhXrtuD6FYFwJqr AJVy_cuaMgzDmpa_3Iq6Pv0CP9jhbuR2XkCPxZAYLDa_SE8iCsNNkijvUqpUOgxzS5LyPKhnGB8P _Yx8sU6qEkVJrIyN_jZsjHGCBKlAo1Q0V_ZAH292lKjylO1TWR5_tXcgfuVljinQMtE2YbjCrtKz l9Hwu0gSg60I199rhVxWfCmunOyQJb0vXvc8vjDn3Z769XeWEjcH86BENbsDwgG5H3ZBI8cQKLc2 NjFCUtjGFCWl9DT2dV6hbuS6FfMOtL7QvGItotPYPkXMMECvPTgFU6BU4ZkaIiLT7STL2s6lmv6_ uo9Ig5CpksIv4KeT..t0BjsEms4VxX_EsXHI0wgQtRpFBom3iFUbyOosVkKTVtCY6PxairRszxA0 f0IAL8pxNXY8jDpZ1BiD6riHqaE2J5XRtpMt5ZcqG3B5aDc5rADuOVKqcyFdHRvUEepwDd.JI3yS VszTgLz9i7Yb6SZVyHn2mgEVd4DU7nTI78jwWrnlHWfivj4TKLAAgpRlxZt7ZqyZIuS0o_g_SHpA whURUjWU_OF6rCt8gKAWZOYWV8HsqFTkTwyO4dxq6KIqSDsu1ymMfYyW5svq9K48BF62MOZwqC2a QQE0Ku.Vx63fozPhWXzFaOQ_zSLH4Of3ZAXq6oOUMDd0kN4sGduMEaBUCKWylBpMEt._0nN.EopW wRAw2gd_T8b_gqk0fmD6j9qJADgU1WvhoBfLyO7GDHCWgUH32DJhfdURbZc..SIlUn4Tf3K8BYpG 3AD8eWq3tJ4uU1CwdHh_BJoDjGcda1crdzyG23nFGVKo7oVde0h9ciS8UBpmclT78tGapHMKMzAg tHuR1H3ikxoyKD63pGWBHT82Z4opPMQ6ohWS8Nz4DGX7MlUogcIPT1otSFOVqevGxNRSViPSNyOb ZY3IxJE9QP3kOf84L9Rmc5IBpbBK72NTPncyH3fYLqD2NMnpPQzZiAFg7EooJHlN_UVZ6MbG5o1. t7rZZspnRLd4f0kwe_lLr9cex5zB6ZlcbW.ME1L6pT218DusxgHMcUwr6nE2CAc7lNMlRFf9Oj_t f_jLcBiaUgyy2FVeUcWlKvW6spfEEm8jY8qb5hNGY1eL0YP0SBzdTZG.m3eFd_QmiF62kG7k_ZQS fbT79zxqPcBgtkerfLd2srbTZ4.jVxf7RlShK7xe1vkxQ2u9lFZPSYYDdrT1Ow6RyPUwdxg7zH1z 6T9Dt7fqWFNkE8t4l5rgrXj2WGzBb8iAlMKscUrycz5gqBFtAQ1MAv4q273L4mArd7An3KwHJIKO LiuT2NMkzGBtzr2laY60MPx5QdqstCkDQPlI.mVWlC6GKtJxb3YivYAH9tLdIHkOgq9Hpx5rqluM pVfK8zqMtaiYcowZfLxDp4lNRmcE88kwUm1kngF4lU8yVQ6SrpHuEQsPq4jrKzSaiHp3veoNdx3P 7ma2lu682lRcV03GKDm9HTMZ7GgJbDHtlJuMYZA5POGCdNJc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 28 Dec 2020 21:19:46 +0000 Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 871a81cc04da9b53a657ccfad585a490; Mon, 28 Dec 2020 21:19:40 +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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> Date: Mon, 28 Dec 2020 13:19:37 -0800 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> References: <20201228044840.GA28380@www.zefox.net> <20201228185622.GB28380@www.zefox.net> <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D4Vn13pShz4l9q X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; 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.69.31: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.31:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.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: Mon, 28 Dec 2020 21:19:50 -0000 On 2020-Dec-28, at 12:55, Mark Millard wrote: > > > On 2020-Dec-28, at 12:07, Mark Millard wrote: > > >> On 2020-Dec-28, at 10:56, bob prohaska wrote: >> >>> On Sun, Dec 27, 2020 at 10:10:18PM -0800, Mark Millard wrote: >>>> >>>> >>>> On 2020-Dec-27, at 20:48, bob prohaska wrote: >>>> >>>>> . . . >>>> >>> I didn't know about LDFLAGS, but a re-try with >>> -j1 and LDFLAGS.lld+= -Wl,--threads=1 >>> (apparently the syntax changed) in /etc/make.conf >>> promptly reproduced the error. >> >> Hmm. It been a while since I did a native build instead of a >> cross build. The cross build context has RAM and does not >> use the assignment so I'd not noticed. >> >> Thanks for the report! > > lld for LLVM 10 always had --no-threads as I now understand > and stable/12 still has/uses/needs LLVM 10.0.1 (with > updates). > > That means that lld from LLVM 11 was in use (FreeBSD > 13's system ld). The build was probably trying to build > some LLVM 10.0.1 final+ materials for bootstrap style > build use in later build stages (older FreeBSD targeting). > It likely had not gotten to the stage of building freebsd > stable/12 material itself. > > Attempting to build devel/llvm10 might well have the same > issue without having to involve an extra FreeBSD source > tree or build. There is another gotcha-issue with the change from --no-threads to --threads=1 based on neither working for both 10.0.x and 11.0.y: which ever one is listed in /etc/make.conf (say) will be wrong for other one of: A) building the bootstrap toolchain B) using the bootstrap toolchain The LDFLAGS.lld definition would need to be conditional on the distinction in order to be correct inside each type of context. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Dec 28 22:04:53 2020 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 606E94C3024 for ; Mon, 28 Dec 2020 22:04:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.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 4D4Wmz3XDwz4nXr for ; Mon, 28 Dec 2020 22:04:51 +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=1609193089; bh=ll2hpg1qyBA9RgsEdypGRZXPEYSz6Ev//JakHZuXYmL=; h=Subject:From:Date:To:From:Subject; b=YpFLUEwdgZNRSNpQyRU5ZjP+9iwBWFe54ves6gusL1/om4YcBRrIUXyHCQB+IIbxbh7FnfBYeNcu8OxD9Gwtk5GZ5yue+TxMT6GvPy08xHVX5d2LyDmVoNaWu8PluesGt1NAvF2X92Ly51OIKRY2Hr8XW9QcZlH1sILwbb4E4Z4MtOrCo1Gdo2/u9SmCh6atRrtVIiW2mtnS5AmF6Y7avpGVk98j86EapbviK9DCQBFxjzOFGob2N3cUurKFClqEngsNnUg6HCQgYJg6zAqMH7RRsSLPZDteU0PRhVfrUxEwU85NyAFOgeraY9BcT/V7pjBgH6aTuNPF6tZl7xHvbg== X-YMail-OSG: JxyezbwVM1ly1px1ffrwkqY8ZbrQq4d1eWNzZvqxvq5qq9sEFWL7dyznviL5mNW zheZtKKJMC.MLmKGQvLwjcn0y.nNbIGfranTVaR47lhZj_aZiVhVPpjv_Btb4SVfCieD.RXS9Px5 knZ7n1vpxgeOGD18MNZqP7ai3F7ZDKzZAwN28YJRdtgVeriRdu2ZsVni.LJToSA4Avl3W5V_c5L1 DCS59mIa2zrkuGFn_zS7cFvfp8WRKz5OdRwJsc_QiBkizRTxFf47YSo1moG6bZClSpkXMxTzcyBj 3_qo4z0tvUk0vZcvs45e.zl.gxzLyHMaWaq9zIqSl1pGSqpZzERhEmLZnsdRUGoQw9.pJDbApRag ktk.wugY6o.4zPoe9Z7I.0jTTwaaoD0ea0sZ7rVui8Rwp1vGDO4oZE6gHMesngq7Wwqr2DtRzswT XqksqqLrS2CymeqmDamZz6CHwjmQH3MakxsuEGL6pPyec3gyIi3IxkxRNfIRHiKrygaVg5DD4o0X pe6mYE_Fco6JdUe6mbJT.FKCEIcG258BmUcO.NGby_ZRFlZVamuXj6nuXxPP.vOyB7RNPvJfLfhB fUkgb4PGoH2yJj2tV3vkABIBlQQ69qgQDwKsV.Hd85RVxFiMywTrLq5ziMX1jFhkuFcIC8sAiKzw 1eK6sKwvfYZr46yyuVLpj_jAMlcnfaZscxUw9JeVb3W_TwFPWiZnKMnK36Qx8cRNtzmitA9BYnHf 1Uht2DrsqCwpAB4GnxKrPARo.bH0rYIYlFv9yTTyjFxQdxKRds8Q8WfZwNB4vhO9RMYQcL8qe6HA kmgSRjQxFaIb22Ga7UVnIYdv7eoSGnQ8NI3Ft22DzwyUqk_nMh9tCC7LuTeTEiYSVaT_zVe97egv 0ZjngzqDOdS8sPKAymz.eo2V5FnsCbSo3HcGbbDfL4kS7vjHsK6GKwsvj7t9Rgv.VvhUYJLbnfur i1VKqtK6Y92wRhvHIOdXcFCQ.EXObUQwf0UE84XDqEMCnyT3mNPIFsATQDu5awhNgR7PpZE3B7Qt 0YQ1Z_mJdVNU29cWQg.oxi67Joo6KV8yn3cqBkdUslChH5GPSbTzuLo9JEwm2kkgruN4CgAUESRK sEmH6p2wZaVuLSwWc7PrqqPWkcfJQW2Jt3yTyhFjVE944x9SqbUWmoHOXsx8mqD39B9VPKR0epdm _p4wTaQHVT3m8trThNRorX4USMvB82E8mDTnofGxkviHUpkvleLv3JNqNUYAiMfr1hazm0yRuMSR u0xaiKgR8HTnhISCmR12Czkk8QRq.8j6.NK495WUBIFl2p7WZ3vvJP7xyba5Z6qS5hEUuMzIvkNk FV2BnfYAgtuYtSqZSmc4UI38EkiNaGj1INMY7sKaVkrnwtNWb.CQzsrridhT9CrzbyGdSMdVKnIz dlBZVprPjJ3xiLjE7TI9dE75_Db7VrfKe7mJnO60qT3KjNEStWnHibkIYAJ0sExxDQV6.BzgTN1q yHNU0jzQRRBiSsOHMgHMtOI73leZfKccgMZiriX52FLAX8kJNwu.jr7TUniLrHIZYzfiu0NrkW.E N.0Effdzz7zvFZ7zcY1LlALNjfKYzUuQyF47QpbAZVvZ7BnDEo5jR.Vb9lHT_wdbQANAZRzW8lM9 PLKYGDR8xMudq0sKjfXm.kBVgDy7YKb8V3aD2ZNkOHhA64yVA.hqDj1RGnpSPSriSxFf6npDua62 JzZpBwxiLLabeD98MVrP33_y_BHafymp496vc0uBxXGmHiB5oxWfD3T3OTI8xfo1ryvoyf93xH0g cTpQf25PmHoI.eGy6BH3JD_xYbBE8zj4Pmln.DIErT28VFC3LR5Sv7moEdP.rp3G.9jeszI.hQwL dDUCZcdrZHumclPgRk_bZhP8ZfOFudED5Kn7rOLQwDRKVRtJ9Sl9JG2dUnV0gx8Z3nJHg.aPHZBW M4WPuPH09vzEw3HcUCbhBFOszIQgn.RqN9_SuzRwI4kQFVqi3HFggLRzmHWFSgQyct9vcv1e7PuQ _mMDZA8XxUGcOPOJG.JTjK3VKb0wElnMc43UMayVT.BOTifXiohLtf9DNUv2k_78xxgOUJuqcile L0VH2LB_NOM0fYbiHnytk0wyjI18jQbFHYX80KLr9OXdJTMOr_OgErhvvTUYyUT.4UxeSrL.EEME CAXKJE72bEOcgBJC6ONle0uqj7.lAub.XUsscaidPScYSpBnd97VDIjNn8f8U5WlYnHjqgPCDmab L1Z0K9y7ziFdCVOXI6.pZe36DJUzvB6PV.lnmmvydklvqK6n54XpeaNISBvUPwoKyyST41fRQDkx 7iuaH_MObveM0DiASzcsHgA0JoTkGFAhV20MjBLN6uo8EoZ5wK.zVZm_D9CwFez6banUo55iQRN5 EVrJ_.bbC7uj_wsv6rD8K9lXYStCaVCAJqHVBmAwMYw0Jlho._wRx0rys2rJvx.AnwtYOcUI3KKm JJdTxjkNPpRvFk6_vbRiBEuuzaL6Frx426_yJDXZqnJm9gWyd Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 28 Dec 2020 22:04:49 +0000 Received: by smtp422.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 34ff01f178b45414407e919e621385ba; Mon, 28 Dec 2020 22:04:45 +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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> Date: Mon, 28 Dec 2020 14:04:43 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201228044840.GA28380@www.zefox.net> <20201228185622.GB28380@www.zefox.net> <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D4Wmz3XDwz4nXr X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.01 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.51)[-0.505]; 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.206: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.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.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: Mon, 28 Dec 2020 22:04:53 -0000 On 2020-Dec-28, at 13:19, Mark Millard wrote: > On 2020-Dec-28, at 12:55, Mark Millard wrote: >>=20 >>=20 >> On 2020-Dec-28, at 12:07, Mark Millard wrote: >>=20 >>=20 >>> On 2020-Dec-28, at 10:56, bob prohaska = wrote: >>>=20 >>>> On Sun, Dec 27, 2020 at 10:10:18PM -0800, Mark Millard wrote: >>>>>=20 >>>>>=20 >>>>> On 2020-Dec-27, at 20:48, bob prohaska wrote: >>>>>=20 >>>>>> . . . >>>>>=20 >>>> I didn't know about LDFLAGS, but a re-try with=20 >>>> -j1 and LDFLAGS.lld+=3D -Wl,--threads=3D1 >>>> (apparently the syntax changed) in /etc/make.conf=20 >>>> promptly reproduced the error.=20 >>>=20 >>> Hmm. It been a while since I did a native build instead of a >>> cross build. The cross build context has RAM and does not >>> use the assignment so I'd not noticed. >>>=20 >>> Thanks for the report! >>=20 >> lld for LLVM 10 always had --no-threads as I now understand >> and stable/12 still has/uses/needs LLVM 10.0.1 (with >> updates). >>=20 >> That means that lld from LLVM 11 was in use (FreeBSD >> 13's system ld). The build was probably trying to build >> some LLVM 10.0.1 final+ materials for bootstrap style >> build use in later build stages (older FreeBSD targeting). >> It likely had not gotten to the stage of building freebsd >> stable/12 material itself. >>=20 >> Attempting to build devel/llvm10 might well have the same >> issue without having to involve an extra FreeBSD source >> tree or build. >=20 > There is another gotcha-issue with the change from --no-threads > to --threads=3D1 based on neither working for both 10.0.x and > 11.0.y: which ever one is listed in /etc/make.conf (say) will be > wrong for other one of: >=20 > A) building the bootstrap toolchain > B) using the bootstrap toolchain >=20 > The LDFLAGS.lld definition would need to be conditional on the > distinction in order to be correct inside each type of context. I've started an experiment going another direction: an armv7 context with lots of RAM (and faster processing) with a 13 attempting to build a stable/12 . It is via a chroot into an armv7 13 world on a 8 GiByte, 4-core Cortex-A57 based OverDrive 1000 running aarch64 13. Each process should still be limited to what 32-bit systems allow but overall the system is not that limited. I used -j4 . If such still got the error, then there would likely be implications about the error and it would be unlikely that it would work on the RPi2 v1.1 . (But I expect that it will not get the error.) Root owns file system involved and is doing the build. It did report: make[1]: "/usr/fbsd/stable-12-src/Makefile.inc1" line 344: = SYSTEM_COMPILER: libclang will be built for bootstrapping a = cross-compiler. make[1]: "/usr/fbsd/stable-12-src/Makefile.inc1" line 349: = SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. I already had a stable-12-src branch from git experiments but the matching worktree was missing despite being still registered. So the worktree recreation was: # git worktree add -f ../stable-12-src stable-12-src Preparing worktree (checking out 'stable-12-src') Updating files: 100% (81363/81363), done. HEAD is now at f4d0bc6aa6b9 MFC r354991-r354992 (by lwhsu) =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 Dec 29 00:14:59 2020 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 1280B4C6206 for ; Tue, 29 Dec 2020 00:14:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 4D4Zg53Ww7z4vh4 for ; Tue, 29 Dec 2020 00:14: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=1609200894; bh=GLb2i3B0wbGUPhJJ7LkXiH2BM7fMZWoIOWYarPpg7lZ=; h=Subject:From:Date:To:From:Subject; b=YQy6cMXuudTgjuQjdCVsHl0mPTQ/wPKDgNeFofaYQyZGPXqlK8ImbhWzzXmRdogli+kpEEZisbNxoL4DRaMn9IKGcLwTH0O0WDLmSZIbDQMswQXybIKZaFTvf4mAuiwStAvum4/dFycM1FJ9FRQZgRuwfXzCnVo9l33X40i77rrnbohgqy+tA4hgPZItRaJkl0JdRzMmQYweZnG2rzhJYWYjU5wJm6C+Pz2/sDwDvg4yX74nqsvGJERKLngCyv3VAib5I5+mCG93+YSg2AvAPgCo5ooggGYGS51ex91H44Uu4qvjAu6jE2pZyam5A9C3F7TsTBvrigITTWwSfxHRmg== X-YMail-OSG: NJuhDyIVM1mpF8NX4MATsT16hIAXrrGvQ0dxTgOmEtUsLzxu8SFL1GN6m6SARMd K8mx84gBKtbNzn0UGEZ_0qVl9_2uxgPyuhh7mUal0rTCitz5GwaBebOXIs3HzpqeAF9ZwpKlhkE6 NItzZgCI7uvuUbHECVJ_vlqGfiYcLQkiC6SuEmXqW.PpRABAO6g3xlZ9fNKAkQNUgxmb6TeAISVJ y8odhjIF.c1n4PtgMwWQUNWz0j9jGm5JbdXsQWhgflVA.admw60sv_NiIw3VXW8gYr3uJODJkdir MmDv2L5DVkikIPqK8Cnd0dRU6ILxbreKMCTuVZbV8AFOCkRMcmLEuTWnjLQ9YlVPGEb2Vcflnim8 dPcEXpQGonaZpQuLsXPSrQJGk3nh_Jcd4q6mhFLUr7jb2eInV6ZlkHZlbUPObHWQOg.cEBkm4101 rNS4SKwRLLZF8nsbBYISqReyW8E91T2C5_ZwNJg5nZHnAeuUZcCrjGtesORVsGRdC5bAI_K0KT4_ GNCkGokRUaNTPClGmr51MVf.i23GCiV0JYr6YHj3YaxzAmbilmSbcMi5i7bWxf_WS2aYKzfEldgJ h4zK4MajZMJBjBBYBwmocxVUsxH4RecaRjOySlZW8C7ejHmmLsyt4gWzn86FzRMkuUM.UCpyh78c oItetPqZwQQeAE_32.Ph7_KcAf1hwSNdS5XuKs3cI6L6..hk742.OaDVibPdGefIKQRLvv.87AUP jg4Rb0IK5Z9AgqN0m2jEfrahho13PiCA348mqQDcWmz0KL51LFDv5.kH5Vlv2OzAp4x9hReNJSk9 iT_u6FMB0v2QQy8Yne5JvduVVumgOpUpyHH9gj99t6KQ4kuH1v7tbso82jV8kTxCtHvN0l2AwOKm HQq8ncNSf6_1yG4H4pDsTan2bu6eEkO.GbHsnX_o3RGUKzTABsxSxEKf0FORoDbnI5rBPnIb5tB8 pHLieqiJrsyxcocYA3tv6Xkc2On_P8mTmS1zDI3n97TVFurlo6ACPCDd1IVpkHCM_K7nBDwE.OMn gHkWrRKmknsQa8K3DksJDI1I8rud.Mk3X6_bbvuYmsj8DWjkWlymq4bwD7CrukroQ.FjKjpMem70 O6LvxKgGDKvibac.81YAJxr08a3IdC9Z0A7do5z5Sgqj9Ci7v5a1CxvAblXN2emLg2wviZq9Wh8l Uxsp2CnE0xb0yOpHmAs_iAoha_.TMFzUymHA_XCVmxgFtvX4VsDFDoMCKG2RpOTz79z_3z_B1Cl_ MpbmUIt.drh_8tvyt2sYRn.U0V9W.GBUZQjbWNETi4ECRdVk8g5JnsqkP4XrSjcf636sDi0WdvT9 94N1VHfp.oPwS1EFs4xKNiJfAK4Yd1.G82SE9OoHEgoDxIZQDWpCNH.8RtQt67MkC92NIH1NQ95E q2YEMtS3t39E7Ug8pX.2b4ecPUQCoYlNiBXcEx0iJHrF2HzwEHqUjtXdPsvQjgemUpdZEI6SKAek wAEiJP.Qe2l4l1TiMld6Qek.Opno3OL05OV5Wdb_mfyHy.xyoa1CNlPZQpiiKSCiZB6heBQoVEha IH.TE.B_yNQKukcMrC1wuapcNMtADTmF5izP8FsHPY5I51wAsBDJ4tYGy.LqF_sO3VyB4u9mUNNq eplS6pF6QDHvZ06sbFqYEdMTxqYIciA0rn1hL7uXvXShN.eS9VZDp.PAo38cQhU6ng_bsFndXb_t 6Gyl2EgRzawbbHK_bfQ9K6aHm8cZZ7Jb2r3Qr2jIr1TKEIRctkqtuLEF9VvjXL9T.4kYFq7UX04o 6jL_2Xza5jnAON3cXN3gp50oka3qskcQ.22swpeYdr6uzqiRDXFgwuIl0wCgCpH99jiBIeWxLBIY vfWu70R2KN.6ygJxlVGg7HkXf_cW3.fhBp6f_uJxpsWCCSXpC90Rq4FW172YZEaT4AJFLFoygR40 f3A9y1bzPVUb9QBMfAhrPZS53WN2m9I3SOouJz1TOtshPCfqhyOvvNcaaoBW63BDP_4VdO0XH8QL jFeEMay3ZwFBI37ix30Dx9Ib67vNn7nN7bU63l2lnw6HJGZMcyKfTaL.a7ra6k5rMPmhbZkaln4R c9BfOJgOa3eckEBG_RHLwiVZXaXMr_qAU.J7UNZIsI_SzawZIcbs5jFOHzgy8q4LYD798yRl8BZY w26xtJz3yXlXEhFLateKYIa9PRAPYQDWKShwp6m_NlWn6q9cvxm4kLG4rognPaAqYnJErR_ZcHPO w0xfOTlHT97_3W7eltO01hJ8ThfqisQ1qo7h06xY0D2IkBhzui7CP09ZfJzsIoZZCqjyS8nyTHN1 UKtilZng17WUuGYXsB39CCq.Uf_qoz2tpjSi0Wx8fMRI9BFjrpBDv_v0t3KLkgPpFtn3fPHAMnhV vuJv2oHtkTcN3isiSTEzw4RWBrqJs.rim2P8XQaD_aDfIIT3t0CZJKUfg6h_8Ls06D0XgYRL.X4m 326fh3LqbtEOh1bdG4ZEvaEaLsU7sW9xnEfFHDywQXwqV4AszKaGtIleiXHdWXIuF0dpzOQqAkW7 k3qnwgBJ5.xtb0IrKI1ZJDOnc3JC9aw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 29 Dec 2020 00:14:54 +0000 Received: by smtp405.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bc845a779b50d5422b10a6e83af0dab5; Tue, 29 Dec 2020 00:14: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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: Date: Mon, 28 Dec 2020 16:14:51 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201228044840.GA28380@www.zefox.net> <20201228185622.GB28380@www.zefox.net> <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D4Zg53Ww7z4vh4 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; 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.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.68.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.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: Tue, 29 Dec 2020 00:14:59 -0000 [I get the problem as well! I report a backtrace of the failure and some more.] On 2020-Dec-28, at 14:04, Mark Millard wrote: > On 2020-Dec-28, at 13:19, Mark Millard wrote: >=20 >> On 2020-Dec-28, at 12:55, Mark Millard wrote: >>>=20 >>>=20 >>> On 2020-Dec-28, at 12:07, Mark Millard wrote: >>>=20 >>>=20 >>>> On 2020-Dec-28, at 10:56, bob prohaska = wrote: >>>>=20 >>>>> On Sun, Dec 27, 2020 at 10:10:18PM -0800, Mark Millard wrote: >>>>>>=20 >>>>>>=20 >>>>>> On 2020-Dec-27, at 20:48, bob prohaska = wrote: >>>>>>=20 >>>>>>> . . . >>>>>>=20 >>>>> I didn't know about LDFLAGS, but a re-try with=20 >>>>> -j1 and LDFLAGS.lld+=3D -Wl,--threads=3D1 >>>>> (apparently the syntax changed) in /etc/make.conf=20 >>>>> promptly reproduced the error.=20 >>>>=20 >>>> Hmm. It been a while since I did a native build instead of a >>>> cross build. The cross build context has RAM and does not >>>> use the assignment so I'd not noticed. >>>>=20 >>>> Thanks for the report! >>>=20 >>> lld for LLVM 10 always had --no-threads as I now understand >>> and stable/12 still has/uses/needs LLVM 10.0.1 (with >>> updates). >>>=20 >>> That means that lld from LLVM 11 was in use (FreeBSD >>> 13's system ld). The build was probably trying to build >>> some LLVM 10.0.1 final+ materials for bootstrap style >>> build use in later build stages (older FreeBSD targeting). >>> It likely had not gotten to the stage of building freebsd >>> stable/12 material itself. >>>=20 >>> Attempting to build devel/llvm10 might well have the same >>> issue without having to involve an extra FreeBSD source >>> tree or build. >>=20 >> There is another gotcha-issue with the change from --no-threads >> to --threads=3D1 based on neither working for both 10.0.x and >> 11.0.y: which ever one is listed in /etc/make.conf (say) will be >> wrong for other one of: >>=20 >> A) building the bootstrap toolchain >> B) using the bootstrap toolchain >>=20 >> The LDFLAGS.lld definition would need to be conditional on the >> distinction in order to be correct inside each type of context. >=20 > I've started an experiment going another direction: an armv7 > context with lots of RAM (and faster processing) with a > 13 attempting to build a stable/12 . It is via a chroot into > an armv7 13 world on a 8 GiByte, 4-core Cortex-A57 based > OverDrive 1000 running aarch64 13. Each process should still > be limited to what 32-bit systems allow but overall the > system is not that limited. I used -j4 . >=20 > If such still got the error, then there would likely be > implications about the error and it would be unlikely > that it would work on the RPi2 v1.1 . (But I expect that > it will not get the error.) >=20 > Root owns file system involved and is doing the build. >=20 > It did report: >=20 > make[1]: "/usr/fbsd/stable-12-src/Makefile.inc1" line 344: = SYSTEM_COMPILER: libclang will be built for bootstrapping a = cross-compiler. > make[1]: "/usr/fbsd/stable-12-src/Makefile.inc1" line 349: = SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. >=20 > I already had a stable-12-src branch from git experiments > but the matching worktree was missing despite being still > registered. So the worktree recreation was: >=20 > # git worktree add -f ../stable-12-src stable-12-src > Preparing worktree (checking out 'stable-12-src') > Updating files: 100% (81363/81363), done. > HEAD is now at f4d0bc6aa6b9 MFC r354991-r354992 (by lwhsu) For armv7 13's context being based on: WITH_ASSERT_DEBUG=3D WITH_LLVM_ASSERTIONS=3D WITHOUT_MALLOC_PRODUCTION=3D WITH_DEBUG_FILES=3D -mcpu=3Dcortex-a7 -g in use despite -O2 or such optimizations. (The WITHOUT_MALLOC_PRODUCTION is because of a typo in the attempt to have set WITH_MALLOC_PRODUCTION.) I was not using --threads=3D1 since it would fail for later build stages. The being-built context was based on: WITH_ASSERT_DEBUG=3D WITHOUT_LLVM_ASSERTIONS=3D WITH_MALLOC_PRODUCTION=3D WITH_DEBUG_FILES=3D -mcpu=3Dcortex-a7 -g in use despite -O2 or such optimizations. I got what follows. (But note that the ARM64TODO: fill_fpregs32c++ is likely from the handling of the process crash already in process and is not contributing to the problem starting.) . . . --- all_subdir_usr.bin/clang/clang --- [Creating objdir = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang...] Building = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/cc1_main.o Building = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/cc1as_main.o Building = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/cc1gen_reproducer_main.o Building = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/driver.o Building = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/clang.full --- clang.full --- LLVM ERROR: out of memory PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and = include the crash backtrace. Stack dump: 0. Program arguments: /usr/bin/ld --eh-frame-hdr -Bstatic -o = clang.full /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legac= y/usr/lib = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libz = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libexecinfo = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libelf = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/ncurses/ncursesw = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libthr -L/usr/lib --gc-sections cc1_main.o cc1as_main.o = cc1gen_reproducer_main.o driver.o = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libclang/libclang.a = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libllvm/libllvm.a -lz -lexecinfo -lelf -lncursesw -lpthread = -legacy -lc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/crtend.o = /usr/lib/crtn.o=20 #0 0x00de160c llvm::sys::PrintStackTrace(llvm::raw_ostream&) = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:572:7 #1 0x00ddf604 llvm::sys::RunSignalHandlers() = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:0:5 #2 0x00de1f3c SignalHandler(int) = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:406:1 #3 0x42021db4 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 ARM64TODO: fill_fpregs32c++: error: unable to execute command: Abort = trap (core dumped) c++: error: linker command failed due to signal (use -v to see = invocation) *** [clang.full] Error code 254 make[4]: stopped in /usr/fbsd/stable-12-src/usr.bin/clang/clang .ERROR_TARGET=3D'clang.full' = .ERROR_META_FILE=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/a= rm.armv7/tmp/obj-tools/usr.bin/clang/clang/clang.full.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'c++ -O -pipe -fno-common -mlong-calls = -I/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/clang/libclang = -I/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/clang/libllvm = -I/usr/fbsd/stable-12-src/contrib/llvm-project/clang/include = -I/usr/fbsd/stable-12-src/lib/clang/include = -I/usr/fbsd/stable-12-src/contrib/llvm-project/llvm/include = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -DHAVE_VCS_VERSION_INC -DNDEBUG = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv7-unknown-freebsd12.2-gnueabihf\" = -DLLVM_HOST_TRIPLE=3D\"armv7-unknown-freebsd12.2\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src= /arm.armv7/tmp\" -DLLVM_TARGET_ENABLE_ARM = -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeARMAsmParser = -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter = -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler = -DLLVM_NATIVE_TARGET=3DLLVMInitializeARMTarget = -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInfo = -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sections = -fdata-sections -gline-tables-only -Wno-format-zero-length = -mcpu=3Dcortex-a7 -Qunused-arguments = -I/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legac= y/usr/include -fno-exceptions -fno-rtti -std=3Dc++14 -mcpu=3Dcortex-a7 = -stdlib=3Dlibc++ -Wno-c++11-extensions -Wl,--gc-sections -static = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legac= y/usr/lib -o clang.full cc1_main.o cc1as_main.o = cc1gen_reproducer_main.o driver.o = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libclang/libclang.a = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libllvm/libllvm.a = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libz -lz = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libexecinfo -lexecinfo = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libelf -lelf = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/ncurses/ncursesw -lncursesw = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libthr -lpthread -legacy;' .CURDIR=3D'/usr/fbsd/stable-12-src/usr.bin/clang/clang' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/= tmp/obj-tools/usr.bin/clang/clang' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm' MACHINE_ARCH=3D'armv7' MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/usr/fbsd/stable-12-src/share/mk' MAKE_VERSION=3D'20201117' = PATH=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp= /legacy/usr/sbin:/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.= armv7/tmp/legacy/usr/bin:/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-= src/arm.armv7/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/fbsd/stable-12-src' = OBJTOP=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/t= mp/obj-tools' .MAKE.MAKEFILES=3D'/usr/fbsd/stable-12-src/share/mk/sys.mk = /usr/fbsd/stable-12-src/share/mk/local.sys.env.mk = /usr/fbsd/stable-12-src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.armv7-clang-bootstrap.armv7-host = /usr/fbsd/stable-12-src/share/mk/bsd.mkopt.mk = /usr/fbsd/stable-12-src/share/mk/src.sys.obj.mk = /usr/fbsd/stable-12-src/share/mk/auto.obj.mk = /usr/fbsd/stable-12-src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf = /usr/fbsd/stable-12-src/share/mk/local.sys.mk = /usr/fbsd/stable-12-src/share/mk/src.sys.mk /dev/null = /usr/fbsd/stable-12-src/usr.bin/clang/clang/Makefile = /usr/fbsd/stable-12-src/share/mk/src.opts.mk = /usr/fbsd/stable-12-src/share/mk/bsd.own.mk = /usr/fbsd/stable-12-src/share/mk/bsd.opts.mk = /usr/fbsd/stable-12-src/share/mk/bsd.cpu.mk = /usr/fbsd/stable-12-src/share/mk/bsd.compiler.mk = /usr/fbsd/stable-12-src/share/mk/bsd.linker.mk = /usr/fbsd/stable-12-src/usr.bin/clang/clang.prog.mk = /usr/fbsd/stable-12-src/lib/clang/clang.pre.mk = /usr/fbsd/stable-12-src/lib/clang/llvm.pre.mk = /usr/fbsd/stable-12-src/lib/clang/clang.build.mk = /usr/fbsd/stable-12-src/lib/clang/llvm.build.mk = /usr/fbsd/stable-12-src/tools/build/mk/bsd.prog.mk = /usr/fbsd/stable-12-src/share/mk/bsd.prog.mk = /usr/fbsd/stable-12-src/share/mk/bsd.init.mk = /usr/fbsd/stable-12-src/share/mk/local.init.mk = /usr/fbsd/stable-12-src/share/mk/src.init.mk = /usr/fbsd/stable-12-src/usr.bin/clang/clang/../Makefile.inc = /usr/fbsd/stable-12-src/usr.bin/clang/clang/../../Makefile.inc = /usr/fbsd/stable-12-src/share/mk/bsd.libnames.mk = /usr/fbsd/stable-12-src/share/mk/src.libnames.mk = /usr/fbsd/stable-12-src/share/mk/bsd.nls.mk = /usr/fbsd/stable-12-src/share/mk/bsd.confs.mk = /usr/fbsd/stable-12-src/share/mk/bsd.files.mk = /usr/fbsd/stable-12-src/share/mk/bsd.dirs.mk = /usr/fbsd/stable-12-src/share/mk/bsd.incs.mk = /usr/fbsd/stable-12-src/share/mk/bsd.links.mk = /usr/fbsd/stable-12-src/share/mk/bsd.dep.mk = /usr/fbsd/stable-12-src/share/mk/bsd.clang-analyze.mk = /usr/fbsd/stable-12-src/share/mk/bsd.obj.mk = /usr/fbsd/stable-12-src/share/mk/bsd.subdir.mk = /usr/fbsd/stable-12-src/share/mk/bsd.sys.mk = /usr/fbsd/stable-12-src/tools/build/mk/Makefile.boot' .PATH=3D'. /usr/fbsd/stable-12-src/usr.bin/clang/clang = /usr/fbsd/stable-12-src/contrib/llvm-project/clang/tools/driver' 1 error # gdb /usr/bin/ld.lld = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/ld.lld.core GNU gdb (GDB) 10.1 [GDB v10.1 for FreeBSD] Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later = . . . Reading symbols from /usr/bin/ld.lld... Reading symbols from /usr/lib/debug//usr/bin/ld.lld.debug... [New LWP 100183] Core was generated by `/usr/bin/ld --eh-frame-hdr -Bstatic -o clang.full = /usr/lib/crt1.o /usr/lib/crti.'. Program terminated with signal SIGABRT, Aborted. #0 thr_kill () at thr_kill.S:4 4 thr_kill.S: No such file or directory. (gdb) info threads Id Target Id Frame=20 * 1 LWP 100183 thr_kill () at thr_kill.S:4(gdb) info threads Id Target Id Frame=20 * 1 LWP 100183 thr_kill () at thr_kill.S:4 (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x4227d998 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x423322c8 in abort () at /usr/src/lib/libc/stdlib/abort.c:79 #3 0x00da5e4c in report_bad_alloc_error () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:174 #4 0x00da61c8 in out_of_memory_new_handler() () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:187 #5 0x420f5d24 in operator new (size=3D) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:73 #6 0x004d995c in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase.h:85= #7 StartNewSlab () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:336 #8 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:188 #9 0x00543388 in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:202 #10 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase.h:46= #11 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase.h:69= #12 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:427 #13 make *, = lld::elf::StringRefZ &, llvm::ELF::(anonymous enum at = /usr/src/contrib/llvm-project/llvm/include/llvm/BinaryFormat/ELF.h:1044:1)= , const unsigned char &, unsigned char &, const = llvm::support::detail::packed_endian_specific_integral &, const = llvm::support::detail::packed_endian_specific_integral &, lld::elf::InputSectionBase *&> () at = /usr/src/contrib/llvm-project/lld/include/lld/Common/Memory.h:62 #14 initializeSymbols () at = /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:1107 #15 0x0053a008 in parse () at = /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:401 #16 doParseFile > () = at /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:208 #17 parseFile () at = /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:215 #18 0x0053b684 in fetch () at = /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:1212 #19 0x005fdce8 in addSymbol () at = /usr/src/contrib/llvm-project/lld/ELF/SymbolTable.cpp:98 #20 0x0053b4b4 in parse () at = /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:1184 #21 0x005143bc in link > () at /usr/src/contrib/llvm-project/lld/ELF/Driver.cpp:1916 #22 0x0050c864 in main () at = /usr/src/contrib/llvm-project/lld/ELF/Driver.cpp:539 #23 0x0050b078 in link () at = /usr/src/contrib/llvm-project/lld/ELF/Driver.cpp:114 #24 0x006be290 in main () at = /usr/src/contrib/llvm-project/lld/tools/lld/lld.cpp:146 The size of the slab being allocated and the allocation initiation are from #7 above: /// Allocate a new slab and move the bump pointers over into the new /// slab, modifying CurPtr and End. void StartNewSlab() { size_t AllocatedSlabSize =3D computeSlabSize(Slabs.size()); void *NewSlab =3D Allocator.Allocate(AllocatedSlabSize, = alignof(std::max_align_t)); . . . This code is associated with the class template: /// Allocate memory in an ever growing pool, as if by bump-pointer. /// =20 /// This isn't strictly a bump-pointer allocator as it uses backing = slabs of /// memory rather than relying on a boundless contiguous heap. However, = it has /// bump-pointer semantics in that it is a monotonically growing pool of = memory /// where every allocation is found by merely allocating the next N = bytes in /// the slab, or the next N bytes in the next slab. /// /// Note that this also has a threshold for forcing allocations above a = certain /// size into their own slab. /// /// The BumpPtrAllocatorImpl template defaults to using a = MallocAllocator /// object, which wraps malloc, to allocate memory, but it can be = changed to /// use a custom allocator. /// /// The GrowthDelay specifies after how many allocated slabs the = allocator /// increases the size of the slabs. template class BumpPtrAllocatorImpl : public AllocatorBase> { . . . The actual malloc call and the later out_of_memory_new_handler call was via #5: // Implement all new and delete operators as weak definitions // in this shared library, so that they can be overridden by programs // that define non-weak copies of the functions. _LIBCPP_WEAK void * operator new(std::size_t size) _THROW_BAD_ALLOC { if (size =3D=3D 0) size =3D 1; void* p; while ((p =3D ::malloc(size)) =3D=3D 0) { // If malloc fails and there is a new_handler, // call it to try free up memory. std::new_handler nh =3D std::get_new_handler(); if (nh) nh(); . . . malloc really did return NULL. It looks like the allocations simply got to be to big in total in process virtual memory space, not necessarily in (contiguous) RAM 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 Tue Dec 29 00:46:46 2020 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 E0AEB4C75EC for ; Tue, 29 Dec 2020 00:46:46 +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 4D4bMn2fYDz4xNr for ; Tue, 29 Dec 2020 00:46: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=1609202803; bh=Qn9qYrmKZU26tCL4D2ff2h2T60l2xpjs4oU62U7raQd=; h=Subject:From:Date:To:From:Subject; b=AitYndjWQ9y7SILdLjkFV22whn+Bi/4OyjbMzOCOe0H8dudTqCE4IocQ/CJPGZA3SluqLSOPArvj3jBKy4ZF28fJXiYiHXzbWAMOH5ay+P7NBtrVuJRgnjXKWMwofmDOSFIW3a+87sMaTuOM2b0y0nHQcAzIL8ILWjVp56VBDPsq9FBBd5+57TRbRQEKeEz67c3ANAJjfJfTvjuvqqZKR6RMDrZu86fmB6NaZj8IYyYONVqsLhvbHiR4PnMUritDdY/LS//8wPGpoOupadIaBhDJtgW5OV15HzAbTe4KIjsNz6Hmggs8rHpbfaBqYox3Rvb3SePJbPQkUhcn431tIQ== X-YMail-OSG: aV1e3jQVM1lwiDM3n8J_IfnC4RSPbeZ5OMzjNKZ_Td318NdR0JM2nqSVUM46eAL XIueVHvV4nrInY1ZjsCPUNzC9yvUH555kAqdi_16GQBsDxxU9kMiYzDCytyHPnvi_A.ZS3tFiv.Q g2uJv8u.TX6ck63GNbL2K2VQdBBU4gM2G6uPmfQ.3hpcq9_gOYJrObeMsizX8R60wVW3SUGyBDuq fGAo2ssA6U8ez_81G5SQtPgG3m8CFyFVafblGEJVR1k8P_qjDqD5Y9dycLR0ZqzNyGU8E3aj0_kD .fZvrViFgyh6nlApYMMzgHArUhSffpgCsIpM0ohl4K4RaLZ0LEJqLRfbebq6865Tm45la5SIV5UE pU2wUdoLD9mWMMoCFDopgN8fJf7ZOOW9ADSepe6Ksvada6iqIpA1viovfdAZSdZI9uLB2nuPKqaC ohrlZhUvOiNJT3YrLn7m8izoSokzzyhO6q8adlYlHKtp3j1Y5pYOBIQyij.rCCYHGa7NQMp_9.TH dxHsf4tmeEtO57QuxOdskiRr_lO0Qm06tjDkv3OJUj2gU_D6Bpeff0.WEtTqT1rovpDGT7Tw5byC CuAsOA32f4T0KBpt_T_2KqYyBnlHXapPIt_66v.KXdHjaVroUPKfOHOLYQmrfR4sN2TV3QEa5kh4 mAbgC_A_Rs_JiVdRVcU6dNKiAj2CSj.4xCj4Nj4Xp8x51vE.0sPyQaGKz2g2Org2hiDoj_xBXGIQ ydPIEYM.kQNB5c8NOU6o3yRtQlNAIPyu9eMzgDQXMI1.UNiDYR.VU5K_eMyFU6JTdMc4v4R3raZU isvb3iypvdwwtk0vos_5tIx8wJxr27kwfnJ1bVn5T9haHxMiyJKwc4NZcwU3G0ODa8UIj1mPCtdj LjqHsPrl7wFA5lFQ.6GKYS5rV9sEXdYFWDUd.Aqd7YkZM0aChRb.nD9JjL.BeLAM2ovkQy1ndU.d ii6tEqteGdxipTmH9BkdcnvUJxx6i9IWM6pGRADiEJLwhYsXWmdbh9paGnukmN8clap055X4TnS8 v7CY52BLXx.bGhsOWpBsLIW2j4yKWJ5ZojHWKm6SR959fTKlYtry0KZa8JxAn.StSdNidKaJpthY zkF2aW7kLaLZcrIgotoe7ulYM5K0zKaC5.rlZObj5kWPJ3IQ9bsEUH6eHClnTeQqupOKj7XWI6lj O5JZLfrVQS39_S1ctgKVJ0kT7ZxA95ZA4qcblu28SlRvmj3e..B9CYdJKUbuLd6VEShwfGKO5gH. pZHxTyejmArpsSy9OqcVG7uo3KNHFnJibdjl0xeJIkpxP.hqL55AJvqWZSn2t7cfS4DAXwDDYnma pyuVUoYmddMeCxfARvAbZ_pAoKCd_V1yTJCjfj9u5FVp1GdO.z0vTiNaNCo35T6C_kDSJ04Ajuo9 7aa3ZAkheqAd6oa4u26QKdKUwdS0oBMEWk6at52G4vpb7E0WVPH_yqRdXlS5EX0MIB2Fnr3m.Q.6 MvFWsgxDGAVIPun.BZmkg7mJWO.YbA3QlncFtjv_gIEIKUbZaTJdaqHMd0aDn.SUGBUHSspywoBO oI7hjVbJdP04E17qbz5FoH78Ex9QJfkk4DAv.BCQRLtYXZQ_fte8LVPjCOG5VOhVHOcboksI5ZqB pyFoX7mjsnPzorGvy2y9iMDHLp_tz88.uK739pkWcuKl9u6k66lAfVXklkjVxnph9T207g7Ltk2R R9zwRlgfQ5upd86mL59PmFVTKFAtxaBLPMBLyQlx.IDD_j5bl1jt2wK1uvRVrnqTPNfVssjNeo5. C2JTCALsATEqlJXksCYNPWKq8Pc3yrgnpvJeLguRLGyk92CGuCgzBV.jDb72UiCfsE2ek2e_U89e AUj8_o3LuLM9K2EkxLQXLpbcWlF9lUiwcQs4m2MK75m2pMLQHLaK2v_jqgm.O8i6.vu8i.McHmJ. J5gZE1s1WojDV_KZfBOMsfwyF1lLcbRybAb7_czY0drBqy.TgpmqL0RL5CzEqylpdQa2JsKL6m_4 m6Kx1g4P7_n9Gy.avksmzSEUq2LUNTJbhFDd6yEFX_57.s_wh2FSVuv9fROYKqb4rmVPdKHN2spL y85aS_qY7PCMX5bXpF1LjEZ9MnxV8FIK3VZTbTT_y5CG4geZFlg4pahB0YDYdCJwVhCOchqIxl5f scW8odkUNDgldxro3MMQuNiG9DTeZNKEx5ZZ2h9FFUD65LVG3FUFSbEfHGHVrPCkCTlDNnzUa9jY 4YQFiVsv39hLzpdig7Y38do28jWgG1y8fXnJVR7.KYC0j.M7SposxXXSVK.kV3aVSpoogj_4Ea5Z E1SIbW441Hzvm0BX6xOFURzg5seSk5spdai2MnIvMtdTCKISihY9CgWn1hfEdJBEebKgLbRve3fm WhCSfexgcjZmNjTjxrJheugFEeSB4TZeJHf57RmEIK398lrOlZoMuZUZizjT1Vx4lCn_J4L8zKz1 VTwZHQ5RW8npq3hfpPG0n2xjXHZXSb4dQnkRiyJpnZF_LVo.Iug-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Tue, 29 Dec 2020 00:46:43 +0000 Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a465c6441edfa924458e26a19cbf87c5; Tue, 29 Dec 2020 00:46: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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: Date: Mon, 28 Dec 2020 16:46:38 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201228044840.GA28380@www.zefox.net> <20201228185622.GB28380@www.zefox.net> <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D4bMn2fYDz4xNr X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; 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: Tue, 29 Dec 2020 00:46:46 -0000 On 2020-Dec-28, at 16:14, Mark Millard wrote: > [I get the problem as well! I report a backtrace of the failure > and some more.] >=20 > On 2020-Dec-28, at 14:04, Mark Millard wrote: >=20 >> On 2020-Dec-28, at 13:19, Mark Millard wrote: >>=20 >>> On 2020-Dec-28, at 12:55, Mark Millard wrote: >>>>=20 >>>>=20 >>>> On 2020-Dec-28, at 12:07, Mark Millard = wrote: >>>>=20 >>>>=20 >>>>> On 2020-Dec-28, at 10:56, bob prohaska = wrote: >>>>>=20 >>>>>> On Sun, Dec 27, 2020 at 10:10:18PM -0800, Mark Millard wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2020-Dec-27, at 20:48, bob prohaska = wrote: >>>>>>>=20 >>>>>>>> . . . >>>>>>>=20 >>>>>> I didn't know about LDFLAGS, but a re-try with=20 >>>>>> -j1 and LDFLAGS.lld+=3D -Wl,--threads=3D1 >>>>>> (apparently the syntax changed) in /etc/make.conf=20 >>>>>> promptly reproduced the error.=20 >>>>>=20 >>>>> Hmm. It been a while since I did a native build instead of a >>>>> cross build. The cross build context has RAM and does not >>>>> use the assignment so I'd not noticed. >>>>>=20 >>>>> Thanks for the report! >>>>=20 >>>> lld for LLVM 10 always had --no-threads as I now understand >>>> and stable/12 still has/uses/needs LLVM 10.0.1 (with >>>> updates). >>>>=20 >>>> That means that lld from LLVM 11 was in use (FreeBSD >>>> 13's system ld). The build was probably trying to build >>>> some LLVM 10.0.1 final+ materials for bootstrap style >>>> build use in later build stages (older FreeBSD targeting). >>>> It likely had not gotten to the stage of building freebsd >>>> stable/12 material itself. >>>>=20 >>>> Attempting to build devel/llvm10 might well have the same >>>> issue without having to involve an extra FreeBSD source >>>> tree or build. >>>=20 >>> There is another gotcha-issue with the change from --no-threads >>> to --threads=3D1 based on neither working for both 10.0.x and >>> 11.0.y: which ever one is listed in /etc/make.conf (say) will be >>> wrong for other one of: >>>=20 >>> A) building the bootstrap toolchain >>> B) using the bootstrap toolchain >>>=20 >>> The LDFLAGS.lld definition would need to be conditional on the >>> distinction in order to be correct inside each type of context. >>=20 >> I've started an experiment going another direction: an armv7 >> context with lots of RAM (and faster processing) with a >> 13 attempting to build a stable/12 . It is via a chroot into >> an armv7 13 world on a 8 GiByte, 4-core Cortex-A57 based >> OverDrive 1000 running aarch64 13. Each process should still >> be limited to what 32-bit systems allow but overall the >> system is not that limited. I used -j4 . >>=20 >> If such still got the error, then there would likely be >> implications about the error and it would be unlikely >> that it would work on the RPi2 v1.1 . (But I expect that >> it will not get the error.) >>=20 >> Root owns file system involved and is doing the build. >>=20 >> It did report: >>=20 >> make[1]: "/usr/fbsd/stable-12-src/Makefile.inc1" line 344: = SYSTEM_COMPILER: libclang will be built for bootstrapping a = cross-compiler. >> make[1]: "/usr/fbsd/stable-12-src/Makefile.inc1" line 349: = SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. >>=20 >> I already had a stable-12-src branch from git experiments >> but the matching worktree was missing despite being still >> registered. So the worktree recreation was: >>=20 >> # git worktree add -f ../stable-12-src stable-12-src >> Preparing worktree (checking out 'stable-12-src') >> Updating files: 100% (81363/81363), done. >> HEAD is now at f4d0bc6aa6b9 MFC r354991-r354992 (by lwhsu) >=20 > For armv7 13's context being based on: >=20 > WITH_ASSERT_DEBUG=3D > WITH_LLVM_ASSERTIONS=3D > WITHOUT_MALLOC_PRODUCTION=3D > WITH_DEBUG_FILES=3D > -mcpu=3Dcortex-a7 > -g in use despite -O2 or such optimizations. >=20 > (The WITHOUT_MALLOC_PRODUCTION is because of a typo > in the attempt to have set WITH_MALLOC_PRODUCTION.) >=20 > I was not using --threads=3D1 since it would fail for later > build stages. >=20 > The being-built context was based on: >=20 > WITH_ASSERT_DEBUG=3D > WITHOUT_LLVM_ASSERTIONS=3D > WITH_MALLOC_PRODUCTION=3D > WITH_DEBUG_FILES=3D > -mcpu=3Dcortex-a7 > -g in use despite -O2 or such optimizations. >=20 > I got what follows. (But note that the ARM64TODO: fill_fpregs32c++ > is likely from the handling of the process crash already in > process and is not contributing to the problem starting.) >=20 > . . . > --- all_subdir_usr.bin/clang/clang --- > [Creating objdir = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang...] > Building = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/cc1_main.o > Building = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/cc1as_main.o > Building = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/cc1gen_reproducer_main.o > Building = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/driver.o > Building = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/clang.full > --- clang.full --- > LLVM ERROR: out of memory > PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and = include the crash backtrace. > Stack dump: > 0. Program arguments: /usr/bin/ld --eh-frame-hdr -Bstatic -o = clang.full /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legac= y/usr/lib = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libz = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libexecinfo = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libelf = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/ncurses/ncursesw = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libthr -L/usr/lib --gc-sections cc1_main.o cc1as_main.o = cc1gen_reproducer_main.o driver.o = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libclang/libclang.a = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libllvm/libllvm.a -lz -lexecinfo -lelf -lncursesw -lpthread = -legacy -lc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/crtend.o = /usr/lib/crtn.o=20 > #0 0x00de160c llvm::sys::PrintStackTrace(llvm::raw_ostream&) = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:572:7 > #1 0x00ddf604 llvm::sys::RunSignalHandlers() = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:0:5 > #2 0x00de1f3c SignalHandler(int) = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:406:1 > #3 0x42021db4 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 > ARM64TODO: fill_fpregs32c++: error: unable to execute command: Abort = trap (core dumped) > c++: error: linker command failed due to signal (use -v to see = invocation) > *** [clang.full] Error code 254 >=20 > make[4]: stopped in /usr/fbsd/stable-12-src/usr.bin/clang/clang > .ERROR_TARGET=3D'clang.full' > = .ERROR_META_FILE=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/a= rm.armv7/tmp/obj-tools/usr.bin/clang/clang/clang.full.meta' > .MAKE.LEVEL=3D'4' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' > _ERROR_CMD=3D'c++ -O -pipe -fno-common -mlong-calls = -I/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/clang/libclang = -I/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/clang/libllvm = -I/usr/fbsd/stable-12-src/contrib/llvm-project/clang/include = -I/usr/fbsd/stable-12-src/lib/clang/include = -I/usr/fbsd/stable-12-src/contrib/llvm-project/llvm/include = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -DHAVE_VCS_VERSION_INC -DNDEBUG = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv7-unknown-freebsd12.2-gnueabihf\" = -DLLVM_HOST_TRIPLE=3D\"armv7-unknown-freebsd12.2\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src= /arm.armv7/tmp\" -DLLVM_TARGET_ENABLE_ARM = -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeARMAsmParser = -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter = -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler = -DLLVM_NATIVE_TARGET=3DLLVMInitializeARMTarget = -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInfo = -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sections = -fdata-sections -gline-tables-only -Wno-format-zero-length = -mcpu=3Dcortex-a7 -Qunused-arguments = -I/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legac= y/usr/include -fno-exceptions -fno-rtti -std=3Dc++14 -mcpu=3Dcortex-a7 = -stdlib=3Dlibc++ -Wno-c++11-extensions -Wl,--gc-sections -static = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legac= y/usr/lib -o clang.full cc1_main.o cc1as_main.o = cc1gen_reproducer_main.o driver.o = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libclang/libclang.a = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libllvm/libllvm.a = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libz -lz = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libexecinfo -lexecinfo = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libelf -lelf = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/ncurses/ncursesw -lncursesw = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libthr -lpthread -legacy;' > .CURDIR=3D'/usr/fbsd/stable-12-src/usr.bin/clang/clang' > .MAKE=3D'make' > = .OBJDIR=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/= tmp/obj-tools/usr.bin/clang/clang' > .TARGETS=3D'all' > DESTDIR=3D'' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'arm' > MACHINE_ARCH=3D'armv7' > MAKEOBJDIRPREFIX=3D'' > MAKESYSPATH=3D'/usr/fbsd/stable-12-src/share/mk' > MAKE_VERSION=3D'20201117' > = PATH=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp= /legacy/usr/sbin:/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.= armv7/tmp/legacy/usr/bin:/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-= src/arm.armv7/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP=3D'/usr/fbsd/stable-12-src' > = OBJTOP=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/t= mp/obj-tools' > .MAKE.MAKEFILES=3D'/usr/fbsd/stable-12-src/share/mk/sys.mk = /usr/fbsd/stable-12-src/share/mk/local.sys.env.mk = /usr/fbsd/stable-12-src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.armv7-clang-bootstrap.armv7-host = /usr/fbsd/stable-12-src/share/mk/bsd.mkopt.mk = /usr/fbsd/stable-12-src/share/mk/src.sys.obj.mk = /usr/fbsd/stable-12-src/share/mk/auto.obj.mk = /usr/fbsd/stable-12-src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf = /usr/fbsd/stable-12-src/share/mk/local.sys.mk = /usr/fbsd/stable-12-src/share/mk/src.sys.mk /dev/null = /usr/fbsd/stable-12-src/usr.bin/clang/clang/Makefile = /usr/fbsd/stable-12-src/share/mk/src.opts.mk = /usr/fbsd/stable-12-src/share/mk/bsd.own.mk = /usr/fbsd/stable-12-src/share/mk/bsd.opts.mk = /usr/fbsd/stable-12-src/share/mk/bsd.cpu.mk = /usr/fbsd/stable-12-src/share/mk/bsd.compiler.mk = /usr/fbsd/stable-12-src/share/mk/bsd.linker.mk = /usr/fbsd/stable-12-src/usr.bin/clang/clang.prog.mk = /usr/fbsd/stable-12-src/lib/clang/clang.pre.mk = /usr/fbsd/stable-12-src/lib/clang/llvm.pre.mk = /usr/fbsd/stable-12-src/lib/clang/clang.build.mk = /usr/fbsd/stable-12-src/lib/clang/llvm.build.mk = /usr/fbsd/stable-12-src/tools/build/mk/bsd.prog.mk = /usr/fbsd/stable-12-src/share/mk/bsd.prog.mk = /usr/fbsd/stable-12-src/share/mk/bsd.init.mk = /usr/fbsd/stable-12-src/share/mk/local.init.mk = /usr/fbsd/stable-12-src/share/mk/src.init.mk = /usr/fbsd/stable-12-src/usr.bin/clang/clang/../Makefile.inc = /usr/fbsd/stable-12-src/usr.bin/clang/clang/../../Makefile.inc = /usr/fbsd/stable-12-src/share/mk/bsd.libnames.mk = /usr/fbsd/stable-12-src/share/mk/src.libnames.mk = /usr/fbsd/stable-12-src/share/mk/bsd.nls.mk = /usr/fbsd/stable-12-src/share/mk/bsd.confs.mk = /usr/fbsd/stable-12-src/share/mk/bsd.files.mk = /usr/fbsd/stable-12-src/share/mk/bsd.dirs.mk = /usr/fbsd/stable-12-src/share/mk/bsd.incs.mk = /usr/fbsd/stable-12-src/share/mk/bsd.links.mk = /usr/fbsd/stable-12-src/share/mk/bsd.dep.mk = /usr/fbsd/stable-12-src/share/mk/bsd.clang-analyze.mk = /usr/fbsd/stable-12-src/share/mk/bsd.obj.mk = /usr/fbsd/stable-12-src/share/mk/bsd.subdir.mk = /usr/fbsd/stable-12-src/share/mk/bsd.sys.mk = /usr/fbsd/stable-12-src/tools/build/mk/Makefile.boot' > .PATH=3D'. /usr/fbsd/stable-12-src/usr.bin/clang/clang = /usr/fbsd/stable-12-src/contrib/llvm-project/clang/tools/driver' > 1 error >=20 > # gdb /usr/bin/ld.lld = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/usr.bin/clang/clang/ld.lld.core > GNU gdb (GDB) 10.1 [GDB v10.1 for FreeBSD] > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later = > . . . > Reading symbols from /usr/bin/ld.lld... > Reading symbols from /usr/lib/debug//usr/bin/ld.lld.debug... > [New LWP 100183] > Core was generated by `/usr/bin/ld --eh-frame-hdr -Bstatic -o = clang.full /usr/lib/crt1.o /usr/lib/crti.'. > Program terminated with signal SIGABRT, Aborted. > #0 thr_kill () at thr_kill.S:4 > 4 thr_kill.S: No such file or directory. > (gdb) info threads > Id Target Id Frame=20 > * 1 LWP 100183 thr_kill () at thr_kill.S:4(gdb) info threads > Id Target Id Frame=20 > * 1 LWP 100183 thr_kill () at thr_kill.S:4 > (gdb) bt > #0 thr_kill () at thr_kill.S:4 > #1 0x4227d998 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x423322c8 in abort () at /usr/src/lib/libc/stdlib/abort.c:79 > #3 0x00da5e4c in report_bad_alloc_error () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:174 > #4 0x00da61c8 in out_of_memory_new_handler() () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:187 > #5 0x420f5d24 in operator new (size=3D) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:73 > #6 0x004d995c in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase.h:85= > #7 StartNewSlab () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:336 > #8 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:188 > #9 0x00543388 in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:202 > #10 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase.h:46= > #11 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase.h:69= > #12 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:427 > #13 make = *, lld::elf::StringRefZ &, llvm::ELF::(anonymous enum at = /usr/src/contrib/llvm-project/llvm/include/llvm/BinaryFormat/ELF.h:1044:1)= , const unsigned char &, unsigned char &, const = llvm::support::detail::packed_endian_specific_integral &, const = llvm::support::detail::packed_endian_specific_integral &, lld::elf::InputSectionBase *&> () at = /usr/src/contrib/llvm-project/lld/include/lld/Common/Memory.h:62 > #14 initializeSymbols () at = /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:1107 > #15 0x0053a008 in parse () at = /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:401 > #16 doParseFile > = () at /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:208 > #17 parseFile () at = /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:215 > #18 0x0053b684 in fetch () at = /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:1212 > #19 0x005fdce8 in addSymbol () at = /usr/src/contrib/llvm-project/lld/ELF/SymbolTable.cpp:98 > #20 0x0053b4b4 in parse () at = /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:1184 > #21 0x005143bc in link > () at /usr/src/contrib/llvm-project/lld/ELF/Driver.cpp:1916 > #22 0x0050c864 in main () at = /usr/src/contrib/llvm-project/lld/ELF/Driver.cpp:539 > #23 0x0050b078 in link () at = /usr/src/contrib/llvm-project/lld/ELF/Driver.cpp:114 > #24 0x006be290 in main () at = /usr/src/contrib/llvm-project/lld/tools/lld/lld.cpp:146 >=20 > The size of the slab being allocated and the allocation initiation > are from #7 above: >=20 > /// Allocate a new slab and move the bump pointers over into the new > /// slab, modifying CurPtr and End. > void StartNewSlab() { > size_t AllocatedSlabSize =3D computeSlabSize(Slabs.size()); >=20 > void *NewSlab =3D > Allocator.Allocate(AllocatedSlabSize, = alignof(std::max_align_t)); > . . . >=20 > This code is associated with the class template: >=20 > /// Allocate memory in an ever growing pool, as if by bump-pointer. > /// =20 > /// This isn't strictly a bump-pointer allocator as it uses backing = slabs of > /// memory rather than relying on a boundless contiguous heap. = However, it has > /// bump-pointer semantics in that it is a monotonically growing pool = of memory > /// where every allocation is found by merely allocating the next N = bytes in > /// the slab, or the next N bytes in the next slab. > /// > /// Note that this also has a threshold for forcing allocations above = a certain > /// size into their own slab. > /// > /// The BumpPtrAllocatorImpl template defaults to using a = MallocAllocator > /// object, which wraps malloc, to allocate memory, but it can be = changed to > /// use a custom allocator. > /// > /// The GrowthDelay specifies after how many allocated slabs the = allocator > /// increases the size of the slabs. > template size_t SizeThreshold =3D SlabSize, size_t GrowthDelay =3D = 128> > class BumpPtrAllocatorImpl > : public AllocatorBase SizeThreshold, = GrowthDelay>> { > . . . >=20 > The actual malloc call and the later out_of_memory_new_handler > call was via #5: >=20 > // Implement all new and delete operators as weak definitions > // in this shared library, so that they can be overridden by programs > // that define non-weak copies of the functions. >=20 > _LIBCPP_WEAK > void * > operator new(std::size_t size) _THROW_BAD_ALLOC > { > if (size =3D=3D 0) > size =3D 1; > void* p; > while ((p =3D ::malloc(size)) =3D=3D 0) > { > // If malloc fails and there is a new_handler, > // call it to try free up memory. > std::new_handler nh =3D std::get_new_handler(); > if (nh) > nh(); > . . . >=20 > malloc really did return NULL. >=20 > It looks like the allocations simply got to be to > big in total in process virtual memory space, not > necessarily in (contiguous) RAM space. Analyzing the assembler and the gdb-reported register values for #5 leads me to conclude that the size requested was in r4 and was: r4 0x80000 524288 in the code (after +8): 0x420f5ce4 <+0>: push {r4, r5, r11, lr} 0x420f5ce8 <+4>: add r11, sp, #8 0x420f5cec <+8>: mov r4, r0 0x420f5cf0 <+12>: cmp r0, #0 0x420f5cf4 <+16>: movweq r4, #1 0x420f5cf8 <+20>: mov r0, r4 0x420f5cfc <+24>: bl 0x42102070 0x420f5d00 <+28>: cmp r0, #0 0x420f5d04 <+32>: popne {r4, r5, r11, pc} 0x420f5d08 <+36>: ldr r5, [pc, #76] ; 0x420f5d5c = <_Znwj+120> 0x420f5d0c <+40>: add r5, pc, r5 0x420f5d10 <+44>: ldr r0, [r5] 0x420f5d14 <+48>: dmb ish 0x420f5d18 <+52>: cmp r0, #0 0x420f5d1c <+56>: beq 0x420f5d38 <_Znwj+84> 0x420f5d20 <+60>: blx r0 =3D> 0x420f5d24 <+64>: mov r0, r4 0x420f5d28 <+68>: bl 0x42102070 0x420f5d2c <+72>: cmp r0, #0 0x420f5d30 <+76>: beq 0x420f5d10 <_Znwj+44> 0x420f5d34 <+80>: pop {r4, r5, r11, pc} 0x420f5d38 <+84>: mov r0, #4 0x420f5d3c <+88>: bl 0x42102260 0x420f5d40 <+92>: bl 0x42103390 0x420f5d44 <+96>: ldr r1, [pc, #20] ; 0x420f5d60 = <_Znwj+124> 0x420f5d48 <+100>: ldr r1, [pc, r1] 0x420f5d4c <+104>: ldr r2, [pc, #16] ; 0x420f5d64 = <_Znwj+128> 0x420f5d50 <+108>: ldr r2, [pc, r2] 0x420f5d54 <+112>: mov lr, pc 0x420f5d58 <+116>: b 0x42102270 0x420f5d5c <+120>: ldrdeq r5, [r3], -r0 0x420f5d60 <+124>: andeq r0, r2, r4, lsr #32 0x420f5d64 <+128>: andeq r0, r2, r0, lsr #32 =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 Dec 29 01:02:23 2020 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 C6A754C7FE6 for ; Tue, 29 Dec 2020 01:02:23 +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 4D4bjp4TdMz4yMP for ; Tue, 29 Dec 2020 01:02:22 +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 0BT12Kg9036456 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 28 Dec 2020 17:02:21 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 0BT12K4R036454; Mon, 28 Dec 2020 17:02:20 -0800 (PST) (envelope-from fbsd) Date: Mon, 28 Dec 2020 17:02:20 -0800 From: bob prohaska To: Mark Millard Cc: bob prohaska , freebsd-arm@freebsd.org Subject: Re: Migrating from -current to stable/12 on RPI2B (ARMv7) Message-ID: <20201229010220.GA36311@www.zefox.net> References: <20201228044840.GA28380@www.zefox.net> <20201228185622.GB28380@www.zefox.net> <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Rspamd-Queue-Id: 4D4bjp4TdMz4yMP 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]; 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: Tue, 29 Dec 2020 01:02:23 -0000 On Mon, Dec 28, 2020 at 04:14:51PM -0800, Mark Millard wrote: > [I get the problem as well! I report a backtrace of the failure > and some more.] > =20 Relieved to see it's reproducible. =20 Thanks for investigating! =20 bob prohaska > On 2020-Dec-28, at 14:04, Mark Millard wrote: >=20 > > On 2020-Dec-28, at 13:19, Mark Millard wrote: > >=20 > >> On 2020-Dec-28, at 12:55, Mark Millard wrote: > >>>=20 > >>>=20 > >>> On 2020-Dec-28, at 12:07, Mark Millard wrote: > >>>=20 > >>>=20 > >>>> On 2020-Dec-28, at 10:56, bob prohaska wrote: > >>>>=20 > >>>>> On Sun, Dec 27, 2020 at 10:10:18PM -0800, Mark Millard wrote: > >>>>>>=20 > >>>>>>=20 > >>>>>> On 2020-Dec-27, at 20:48, bob prohaska wrote: > >>>>>>=20 > >>>>>>> . . . > >>>>>>=20 > >>>>> I didn't know about LDFLAGS, but a re-try with=20 > >>>>> -j1 and LDFLAGS.lld+=3D -Wl,--threads=3D1 > >>>>> (apparently the syntax changed) in /etc/make.conf=20 > >>>>> promptly reproduced the error.=20 > >>>>=20 > >>>> Hmm. It been a while since I did a native build instead of a > >>>> cross build. The cross build context has RAM and does not > >>>> use the assignment so I'd not noticed. > >>>>=20 > >>>> Thanks for the report! > >>>=20 > >>> lld for LLVM 10 always had --no-threads as I now understand > >>> and stable/12 still has/uses/needs LLVM 10.0.1 (with > >>> updates). > >>>=20 > >>> That means that lld from LLVM 11 was in use (FreeBSD > >>> 13's system ld). The build was probably trying to build > >>> some LLVM 10.0.1 final+ materials for bootstrap style > >>> build use in later build stages (older FreeBSD targeting). > >>> It likely had not gotten to the stage of building freebsd > >>> stable/12 material itself. > >>>=20 > >>> Attempting to build devel/llvm10 might well have the same > >>> issue without having to involve an extra FreeBSD source > >>> tree or build. > >>=20 > >> There is another gotcha-issue with the change from --no-threads > >> to --threads=3D1 based on neither working for both 10.0.x and > >> 11.0.y: which ever one is listed in /etc/make.conf (say) will be > >> wrong for other one of: > >>=20 > >> A) building the bootstrap toolchain > >> B) using the bootstrap toolchain > >>=20 > >> The LDFLAGS.lld definition would need to be conditional on the > >> distinction in order to be correct inside each type of context. > >=20 > > I've started an experiment going another direction: an armv7 > > context with lots of RAM (and faster processing) with a > > 13 attempting to build a stable/12 . It is via a chroot into > > an armv7 13 world on a 8 GiByte, 4-core Cortex-A57 based > > OverDrive 1000 running aarch64 13. Each process should still > > be limited to what 32-bit systems allow but overall the > > system is not that limited. I used -j4 . > >=20 > > If such still got the error, then there would likely be > > implications about the error and it would be unlikely > > that it would work on the RPi2 v1.1 . (But I expect that > > it will not get the error.) > >=20 > > Root owns file system involved and is doing the build. > >=20 > > It did report: > >=20 > > make[1]: "/usr/fbsd/stable-12-src/Makefile.inc1" line 344: SYSTEM_COMPI= LER: libclang will be built for bootstrapping a cross-compiler. > > make[1]: "/usr/fbsd/stable-12-src/Makefile.inc1" line 349: SYSTEM_LINKE= R: libclang will be built for bootstrapping a cross-linker. > >=20 > > I already had a stable-12-src branch from git experiments > > but the matching worktree was missing despite being still > > registered. So the worktree recreation was: > >=20 > > # git worktree add -f ../stable-12-src stable-12-src > > Preparing worktree (checking out 'stable-12-src') > > Updating files: 100% (81363/81363), done. > > HEAD is now at f4d0bc6aa6b9 MFC r354991-r354992 (by lwhsu) >=20 > For armv7 13's context being based on: >=20 > WITH_ASSERT_DEBUG=3D > WITH_LLVM_ASSERTIONS=3D > WITHOUT_MALLOC_PRODUCTION=3D > WITH_DEBUG_FILES=3D > -mcpu=3Dcortex-a7 > -g in use despite -O2 or such optimizations. >=20 > (The WITHOUT_MALLOC_PRODUCTION is because of a typo > in the attempt to have set WITH_MALLOC_PRODUCTION.) >=20 > I was not using --threads=3D1 since it would fail for later > build stages. >=20 > The being-built context was based on: >=20 > WITH_ASSERT_DEBUG=3D > WITHOUT_LLVM_ASSERTIONS=3D > WITH_MALLOC_PRODUCTION=3D > WITH_DEBUG_FILES=3D > -mcpu=3Dcortex-a7 > -g in use despite -O2 or such optimizations. >=20 > I got what follows. (But note that the ARM64TODO: fill_fpregs32c++ > is likely from the handling of the process crash already in > process and is not contributing to the problem starting.) >=20 > . . . > --- all_subdir_usr.bin/clang/clang --- > [Creating objdir /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm= =2Earmv7/tmp/obj-tools/usr.bin/clang/clang...] > Building /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/t= mp/obj-tools/usr.bin/clang/clang/cc1_main.o > Building /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/t= mp/obj-tools/usr.bin/clang/clang/cc1as_main.o > Building /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/t= mp/obj-tools/usr.bin/clang/clang/cc1gen_reproducer_main.o > Building /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/t= mp/obj-tools/usr.bin/clang/clang/driver.o > Building /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/t= mp/obj-tools/usr.bin/clang/clang/clang.full > --- clang.full --- > LLVM ERROR: out of memory > PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and includ= e the crash backtrace. > Stack dump: > 0. Program arguments: /usr/bin/ld --eh-frame-hdr -Bstatic -o clang.f= ull /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o -L/usr/obj/rpi2_cl= ang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legacy/usr/lib -L/usr/ob= j/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-tools/lib/l= ibz -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/ob= j-tools/lib/libexecinfo -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-= src/arm.armv7/tmp/obj-tools/lib/libelf -L/usr/obj/rpi2_clang/arm.armv7/usr/= fbsd/stable-12-src/arm.armv7/tmp/obj-tools/lib/ncurses/ncursesw -L/usr/obj/= rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-tools/lib/lib= thr -L/usr/lib --gc-sections cc1_main.o cc1as_main.o cc1gen_reproducer_main= =2Eo driver.o /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv= 7/tmp/obj-tools/lib/clang/libclang/libclang.a /usr/obj/rpi2_clang/arm.armv7= /usr/fbsd/stable-12-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm/libllvm.a= -lz -lexecinfo -lelf -lncursesw -lpthread -legacy -lc++ -lm -lgcc -lgcc_eh= -lc -lgcc -lgcc_eh /usr/lib/crtend.o /usr/lib/crtn.o=20 > #0 0x00de160c llvm::sys::PrintStackTrace(llvm::raw_ostream&) /usr/src/con= trib/llvm-project/llvm/lib/Support/Unix/Signals.inc:572:7 > #1 0x00ddf604 llvm::sys::RunSignalHandlers() /usr/src/contrib/llvm-projec= t/llvm/lib/Support/Signals.cpp:0:5 > #2 0x00de1f3c SignalHandler(int) /usr/src/contrib/llvm-project/llvm/lib/S= upport/Unix/Signals.inc:406:1 > #3 0x42021db4 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 > ARM64TODO: fill_fpregs32c++: error: unable to execute command: Abort trap= (core dumped) > c++: error: linker command failed due to signal (use -v to see invocation) > *** [clang.full] Error code 254 >=20 > make[4]: stopped in /usr/fbsd/stable-12-src/usr.bin/clang/clang > .ERROR_TARGET=3D'clang.full' > .ERROR_META_FILE=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/= arm.armv7/tmp/obj-tools/usr.bin/clang/clang/clang.full.meta' > .MAKE.LEVEL=3D'4' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' > _ERROR_CMD=3D'c++ -O -pipe -fno-common -mlong-calls -I/usr/obj/rpi2_clang= /arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-tools/lib/clang/libclan= g -I/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-= tools/lib/clang/libllvm -I/usr/fbsd/stable-12-src/contrib/llvm-project/clan= g/include -I/usr/fbsd/stable-12-src/lib/clang/include -I/usr/fbsd/stable-12= -src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FO= RMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DNDEBUG -DLLVM_DE= FAULT_TARGET_TRIPLE=3D\"armv7-unknown-freebsd12.2-gnueabihf\" -DLLVM_HOST_T= RIPLE=3D\"armv7-unknown-freebsd12.2\" -DDEFAULT_SYSROOT=3D\"/usr/obj/rpi2_c= lang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp\" -DLLVM_TARGET_ENABLE_= ARM -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeARMAsmParser -DLLVM_NATIVE_ASMP= RINTER=3DLLVMInitializeARMAsmPrinter -DLLVM_NATIVE_DISASSEMBLER=3DLLVMIniti= alizeARMDisassembler -DLLVM_NATIVE_TARGET=3DLLVMInitializeARMTarget -DLLVM_= NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInfo -DLLVM_NATIVE_TARGETMC=3DLL= VMInitializeARMTargetMC -ffunction-sections -fdata-sections -gline-tables-o= nly -Wno-format-zero-length -mcpu=3Dcortex-a7 -Qunused-arguments -I/usr/obj= /rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legacy/usr/inclu= de -fno-exceptions -fno-rtti -std=3Dc++14 -mcpu=3Dcortex-a7 -stdlib=3Dlibc+= + -Wno-c++11-extensions -Wl,--gc-sections -static -L/usr/obj/rpi2_clang/a= rm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legacy/usr/lib -o clang.full = cc1_main.o cc1as_main.o cc1gen_reproducer_main.o driver.o /usr/obj/rpi2_cl= ang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-tools/lib/clang/libc= lang/libclang.a /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.ar= mv7/tmp/obj-tools/lib/clang/libllvm/libllvm.a -L/usr/obj/rpi2_clang/arm.arm= v7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-tools/lib/libz -lz -L/usr/obj/r= pi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-tools/lib/libe= xecinfo -lexecinfo -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/a= rm.armv7/tmp/obj-tools/lib/libelf -lelf -L/usr/obj/rpi2_clang/arm.armv7/usr= /fbsd/stable-12-src/arm.armv7/tmp/obj-tools/lib/ncurses/ncursesw -lncursesw= -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libthr -lpthread -legacy;' > .CURDIR=3D'/usr/fbsd/stable-12-src/usr.bin/clang/clang' > .MAKE=3D'make' > .OBJDIR=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7= /tmp/obj-tools/usr.bin/clang/clang' > .TARGETS=3D'all' > DESTDIR=3D'' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'arm' > MACHINE_ARCH=3D'armv7' > MAKEOBJDIRPREFIX=3D'' > MAKESYSPATH=3D'/usr/fbsd/stable-12-src/share/mk' > MAKE_VERSION=3D'20201117' > PATH=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tm= p/legacy/usr/sbin:/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.= armv7/tmp/legacy/usr/bin:/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-s= rc/arm.armv7/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP=3D'/usr/fbsd/stable-12-src' > OBJTOP=3D'/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/= tmp/obj-tools' > .MAKE.MAKEFILES=3D'/usr/fbsd/stable-12-src/share/mk/sys.mk /usr/fbsd/stab= le-12-src/share/mk/local.sys.env.mk /usr/fbsd/stable-12-src/share/mk/src.sy= s.env.mk /root/src.configs/src.conf.armv7-clang-bootstrap.armv7-host /usr/f= bsd/stable-12-src/share/mk/bsd.mkopt.mk /usr/fbsd/stable-12-src/share/mk/sr= c.sys.obj.mk /usr/fbsd/stable-12-src/share/mk/auto.obj.mk /usr/fbsd/stable-= 12-src/share/mk/bsd.suffixes.mk /root/src.configs/make.conf /usr/fbsd/stabl= e-12-src/share/mk/local.sys.mk /usr/fbsd/stable-12-src/share/mk/src.sys.mk = /dev/null /usr/fbsd/stable-12-src/usr.bin/clang/clang/Makefile /usr/fbsd/st= able-12-src/share/mk/src.opts.mk /usr/fbsd/stable-12-src/share/mk/bsd.own.m= k /usr/fbsd/stable-12-src/share/mk/bsd.opts.mk /usr/fbsd/stable-12-src/shar= e/mk/bsd.cpu.mk /usr/fbsd/stable-12-src/share/mk/bsd.compiler.mk /usr/fbsd/= stable-12-src/share/mk/bsd.linker.mk /usr/fbsd/stable-12-src/usr.bin/clang/= clang.prog.mk /usr/fbsd/stable-12-src/lib/clang/clang.pre.mk /usr/fbsd/stab= le-12-src/lib/clang/llvm.pre.mk /usr/fbsd/stable-12-src/lib/clang/clang.bui= ld.mk /usr/fbsd/stable-12-src/lib/clang/llvm.build.mk /usr/fbsd/stable-12-s= rc/tools/build/mk/bsd.prog.mk /usr/fbsd/stable-12-src/share/mk/bsd.prog.mk = /usr/fbsd/stable-12-src/share/mk/bsd.init.mk /usr/fbsd/stable-12-src/share/= mk/local.init.mk /usr/fbsd/stable-12-src/share/mk/src.init.mk /usr/fbsd/sta= ble-12-src/usr.bin/clang/clang/../Makefile.inc /usr/fbsd/stable-12-src/usr.= bin/clang/clang/../../Makefile.inc /usr/fbsd/stable-12-src/share/mk/bsd.lib= names.mk /usr/fbsd/stable-12-src/share/mk/src.libnames.mk /usr/fbsd/stable-= 12-src/share/mk/bsd.nls.mk /usr/fbsd/stable-12-src/share/mk/bsd.confs.mk /u= sr/fbsd/stable-12-src/share/mk/bsd.files.mk /usr/fbsd/stable-12-src/share/m= k/bsd.dirs.mk /usr/fbsd/stable-12-src/share/mk/bsd.incs.mk /usr/fbsd/stable= -12-src/share/mk/bsd.links.mk /usr/fbsd/stable-12-src/share/mk/bsd.dep.mk /= usr/fbsd/stable-12-src/share/mk/bsd.clang-analyze.mk /usr/fbsd/stable-12-sr= c/share/mk/bsd.obj.mk /usr/fbsd/stable-12-src/share/mk/bsd.subdir.mk /usr/f= bsd/stable-12-src/share/mk/bsd.sys.mk /usr/fbsd/stable-12-src/tools/build/m= k/Makefile.boot' > .PATH=3D'. /usr/fbsd/stable-12-src/usr.bin/clang/clang /usr/fbsd/stable-1= 2-src/contrib/llvm-project/clang/tools/driver' > 1 error >=20 > # gdb /usr/bin/ld.lld /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-sr= c/arm.armv7/tmp/obj-tools/usr.bin/clang/clang/ld.lld.core > GNU gdb (GDB) 10.1 [GDB v10.1 for FreeBSD] > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > . . . > Reading symbols from /usr/bin/ld.lld... > Reading symbols from /usr/lib/debug//usr/bin/ld.lld.debug... > [New LWP 100183] > Core was generated by `/usr/bin/ld --eh-frame-hdr -Bstatic -o clang.full = /usr/lib/crt1.o /usr/lib/crti.'. > Program terminated with signal SIGABRT, Aborted. > #0 thr_kill () at thr_kill.S:4 > 4 thr_kill.S: No such file or directory. > (gdb) info threads > Id Target Id Frame=20 > * 1 LWP 100183 thr_kill () at thr_kill.S:4(gdb) info threads > Id Target Id Frame=20 > * 1 LWP 100183 thr_kill () at thr_kill.S:4 > (gdb) bt > #0 thr_kill () at thr_kill.S:4 > #1 0x4227d998 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x423322c8 in abort () at /usr/src/lib/libc/stdlib/abort.c:79 > #3 0x00da5e4c in report_bad_alloc_error () at /usr/src/contrib/llvm-proj= ect/llvm/lib/Support/ErrorHandling.cpp:174 > #4 0x00da61c8 in out_of_memory_new_handler() () at /usr/src/contrib/llvm= -project/llvm/lib/Support/ErrorHandling.cpp:187 > #5 0x420f5d24 in operator new (size=3D) at /usr/src/contr= ib/llvm-project/libcxx/src/new.cpp:73 > #6 0x004d995c in Allocate () at /usr/src/contrib/llvm-project/llvm/inclu= de/llvm/Support/AllocatorBase.h:85 > #7 StartNewSlab () at /usr/src/contrib/llvm-project/llvm/include/llvm/Su= pport/Allocator.h:336 > #8 Allocate () at /usr/src/contrib/llvm-project/llvm/include/llvm/Suppor= t/Allocator.h:188 > #9 0x00543388 in Allocate () at /usr/src/contrib/llvm-project/llvm/inclu= de/llvm/Support/Allocator.h:202 > #10 Allocate () at /usr/src/contrib/llvm-project/llvm/include/llvm/Suppor= t/AllocatorBase.h:46 > #11 Allocate () at /usr/src/contrib/llvm-project/llvm/= include/llvm/Support/AllocatorBase.h:69 > #12 Allocate () at /usr/src/contrib/llvm-project/llvm/include/llvm/Suppor= t/Allocator.h:427 > #13 make *, l= ld::elf::StringRefZ &, llvm::ELF::(anonymous enum at /usr/src/contrib/llvm-= project/llvm/include/llvm/BinaryFormat/ELF.h:1044:1), const unsigned char &= , unsigned char &, const llvm::support::detail::packed_endian_specific_inte= gral &, const llvm::support::det= ail::packed_endian_specific_integral &, lld::elf::InputSectionBase *&> () at /usr/src/contrib/llvm-project/= lld/include/lld/Common/Memory.h:62 > #14 initializeSymbols () at /usr/src/contrib/llvm-project/lld/ELF/InputFi= les.cpp:1107 > #15 0x0053a008 in parse () at /usr/src/contrib/llvm-project/lld/ELF/Input= Files.cpp:401 > #16 doParseFile > () = at /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:208 > #17 parseFile () at /usr/src/contrib/llvm-project/lld/ELF/InputFiles.cpp:= 215 > #18 0x0053b684 in fetch () at /usr/src/contrib/llvm-project/lld/ELF/Input= Files.cpp:1212 > #19 0x005fdce8 in addSymbol () at /usr/src/contrib/llvm-project/lld/ELF/S= ymbolTable.cpp:98 > #20 0x0053b4b4 in parse () at /usr/src/contrib/llvm-project/lld/ELF/Input= Files.cpp:1184 > #21 0x005143bc in link > () at /usr/src/contrib/llvm-project/lld/ELF/Driver.cpp:1916 > #22 0x0050c864 in main () at /usr/src/contrib/llvm-project/lld/ELF/Driver= =2Ecpp:539 > #23 0x0050b078 in link () at /usr/src/contrib/llvm-project/lld/ELF/Driver= =2Ecpp:114 > #24 0x006be290 in main () at /usr/src/contrib/llvm-project/lld/tools/lld/= lld.cpp:146 >=20 > The size of the slab being allocated and the allocation initiation > are from #7 above: >=20 > /// Allocate a new slab and move the bump pointers over into the new > /// slab, modifying CurPtr and End. > void StartNewSlab() { > size_t AllocatedSlabSize =3D computeSlabSize(Slabs.size()); >=20 > void *NewSlab =3D > Allocator.Allocate(AllocatedSlabSize, alignof(std::max_align_t)); > . . . >=20 > This code is associated with the class template: >=20 > /// Allocate memory in an ever growing pool, as if by bump-pointer. > /// =20 > /// This isn't strictly a bump-pointer allocator as it uses backing slabs= of > /// memory rather than relying on a boundless contiguous heap. However, i= t has > /// bump-pointer semantics in that it is a monotonically growing pool of = memory > /// where every allocation is found by merely allocating the next N bytes= in > /// the slab, or the next N bytes in the next slab. > /// > /// Note that this also has a threshold for forcing allocations above a c= ertain > /// size into their own slab. > /// > /// The BumpPtrAllocatorImpl template defaults to using a MallocAllocator > /// object, which wraps malloc, to allocate memory, but it can be changed= to > /// use a custom allocator. > /// > /// The GrowthDelay specifies after how many allocated slabs the allocator > /// increases the size of the slabs. > template size_t SizeThreshold =3D SlabSize, size_t GrowthDelay =3D 128> > class BumpPtrAllocatorImpl > : public AllocatorBase SizeThreshold, GrowthDela= y>> { > . . . >=20 > The actual malloc call and the later out_of_memory_new_handler > call was via #5: >=20 > // Implement all new and delete operators as weak definitions > // in this shared library, so that they can be overridden by programs > // that define non-weak copies of the functions. >=20 > _LIBCPP_WEAK > void * > operator new(std::size_t size) _THROW_BAD_ALLOC > { > if (size =3D=3D 0) > size =3D 1; > void* p; > while ((p =3D ::malloc(size)) =3D=3D 0) > { > // If malloc fails and there is a new_handler, > // call it to try free up memory. > std::new_handler nh =3D std::get_new_handler(); > if (nh) > nh(); > . . . >=20 > malloc really did return NULL. >=20 > It looks like the allocations simply got to be to > big in total in process virtual memory space, not > necessarily in (contiguous) RAM space. >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 >=20 From owner-freebsd-arm@freebsd.org Tue Dec 29 08:16:11 2020 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 15DD24D4C74 for ; Tue, 29 Dec 2020 08:16:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.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 4D4nLK3c5Wz3hJ7 for ; Tue, 29 Dec 2020 08:16:09 +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=1609229766; bh=tI2sIi+/Cachb9gLidvKVp9Awy0oY5fCTVKLIyW0D8V=; h=Subject:From:Date:To:From:Subject; b=L0kb3GWQU8I9+EjQ8jex/gCNhEQO8BcHwvqHLSsiSXgCMptMhqDM5ktzoVSHXgOGlMQ1TThdLR8B+F8VUmLniGOesxUU/Fx/gilrO+D/slcZiYuDOD3u6ZutTyfL5lNpsv+MGbWaGDt0I1oH/D7+jQxbnrEYJuVGIfzE9l1/TU+FcvL5xuvoZX5fbxnUakBUmeErXoNwqB59oGpxtfI37CPuTK4As2yYjFcHU2J4p/r57ByoXW5Tk7Jen5GbfA6y3OjkFmVLIIctZHNknovttWMh77AoEoz6WuEPdwBfOpraTs/aJqtjYFMTbysLh7JS1XlaIdyXjywOyVXwi2AJoQ== X-YMail-OSG: AmkAvSEVM1kQBYY4UGB5JNsYYqJFMmra1qkKUH2gNzrxE3WCgSA8vFGpAo4cvxi kj.rHQRpy.q0FXKfoTOGPYNTVkBfRnH5nDowxXU__XgaPdVwWvltNwRL3p3M7TY.DCCppEye8JQu 4iqJrnZWWQK8Bk.xqJmkDkoaSk558.I6uqgPjs7gHPPliz.qkSR7UxIvjVpB.r4P8zBBwI0uRVyU Qde2DA32X6XMrNNUyes230i3jj4rZOW.J_LWM6f5KWsKqML0QpD_92pl87cu5c2_4FhqCow4aH7u .JeDUfEf1aDQ4Iv6hdC_2UpJ.WoV7EiPJMYQyNfrwuH6i_PnGsVNjUTbxzI0.6WrE0AOZ_aWb0db 70db.DkdXMPRPRkJ_fnrxR.eUS_pY726dMljyxyLnmwkGD21EJR2CDts6Xn95HpWEzfuKUIRLFtz XW3da89aSObkeyu_5Y2s1oA2PLPlhzxpz9ToxxeYIZndSAQtxLAxmEVaVxLqHQr9E3JR1soFH9RM 85n1..LoN_uij6hN5EGsceFFppc1SXQ_YtfDFGP_oyTUvbn47YG9rLmKlJcg.b1AaH7LbfE8GVsO untsjBOcAZxUNB0S_eJFq8VsZj_wnSoEjAV19J6I9a2W4FNh8TkNYFhu1IWlwseTXV6HzVXWs7uj XpzGnwlFaEP0A0f5WCn.o.wFSZPwbtckvd5kJDB9pDabn3Zdlua5d2Brg4s4fNELumHaycbLhst2 wa5UoUJXJb5HMeFeWDR_v8FN9H3i67xGwqa.GhTWilxJIRRAcyG6C5pjoSkeYL.WW8dBPMhguluJ 2GvLBdsjdXOiikCj79aTl7jpDja1R7xFiNmnONkbWEHZUHwwWWCkDBqWRM4R0eqgus4HNDLMvQ2A H4oN_f39I8uGlPzNT8XrZM8UrZxQit5UW0jkRMFyAxBlGoGdoZtZQgtBR.6mEwvUoTIeJ9tIRFoR 19yrns3ew5w0qqn2VqkE0dI7rz0LxyGv9EIDjlC84vfFIX2mR1710R03s1Q_yjEPa3x7qJvn6e2Q 2Bk3nK_I_eUQZ7MjD7RkoLAVJbKeWA5VCAXhvrdbohcXTNv9sKYABL8wRyLuSVMXq4zcTJGoA11F JGgouoNCcjaqYTwSx1TDhpybbUS361gYY.kpy6n90x_9AsZm8WNuk5ejAOfKrh.7lUHdRXTO46KD yLXfFbkTUTHCC_bMx.LnOsBq3hKwo5XdbcK00CYlJMfbEttbwYR68HTE0nbnCm_vHn76nDeliaW4 E979zLXVR1cM6yLg3Iv7VUT_3ocWSE0ro_ixytk5ivvQw5o3hWsn8J4fXz_S5pqwqO15Tj8znhLn 2_dtu_sFw73DA08CXlnfMjkHCfpuJGJBouG.DtmET_ocg72PCdqW.rv_j7HnGZQXQPXBqT324Fm7 z5Z7jQ7M5_bxeFpWBB9ib0P0YhI._kCRITdTL1zSaFRRcfv99tFBmcALkKDdY.rpz6eNJV8m2aUK KQCWRyajSVpSc4XJOiKA_5Ayomx8oijwHTiDHtnNaNjgoKGHmfu8RRKlCmWtIUgmV0nTwpD25ecp aIV2BNaBx3pSa.HTPFGOlvd9kVDGW6t3heuOgbX_3LTxdjB6HWhZMAMLulvRPUVqMJkyI9IHEXe2 vRcskpuhb46VaQLjXVb1vica7tKuUMVSaoYaCtEyrZPIzyP006cBL7P20.l99ZHHuXRb9UA_6UN0 bBQNRACwRAXlfsxGawF5aEj9vJ9ImXYE6hniVfiWZWl.SV_534.Y4zGsjgksAD0uhkhoWcDfIEjO 4orQnaMAnvvzxhxhyEVG9E_ehgMpAfOBZSl_kuzTv199vaC.LNe6QT5edJWD77zC_m41uum3gzYM IsKRKPylyU2M0fq99wZL2rhGLcHpQhNUS9sbCLF0xs14uduJQZTkNah3BpmII_38_A_FDvjPYMMN aGxx48eDu5r5uPIwUvZ1qkJqAVN7SgttIGxSOkzkNkoZ4u6vFO6.cttfJhfBkt2ploYYL7PfEoh5 K.CQ0AWaUXES6cyLvTxFSVvMjGFBKXE.5vjvUFnlyfJjxawBJTDH5wPXQJZHWTb9DGuCy66FQXkw KqPMOWeXI89eG1JugwW.UgBI0xe_6ZvCAMYObWnSyu60aJzza6o.HirVoW.MLhZRdGG175fqWrMc 2_xvPUbtpChnH3lif1yCt8cCvPKg4pvRAAZARztM0noA48nuJaOv2DlOsKNZjQKPXNfA.W4akhyO yHyuGXYPe61cOmIeDfVqkDi7a5Bb8eZgViZEJLva7h8E0BHbG_lAfDoZZS4IN69zeV81vUjcvn6Z q9iWPEBqefhZWrRgkhjwQ4xNMTyoY4qS6QHCxI.qZ1E6r80pzLUG6AOWg79A9ew9G9THX6WFfmzN eg0md7jfEnBkW.guJUTJ6n7F1bOv8GaHyDrk5_UZ3yaBvyK31QbZ8vZ8kXALu3SVOBVpnKHNCZy0 tM1eo7QSLRNFrl7HeLF0ReWsJ.6Zu1X3s Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 29 Dec 2020 08:16:06 +0000 Received: by smtp412.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 72517ba0b18aca3384c82b24d0397296; Tue, 29 Dec 2020 08:16:04 +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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <20201229010220.GA36311@www.zefox.net> Date: Tue, 29 Dec 2020 00:16:02 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> References: <20201228044840.GA28380@www.zefox.net> <20201228185622.GB28380@www.zefox.net> <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> <20201229010220.GA36311@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D4nLK3c5Wz3hJ7 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.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)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.30:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.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: Tue, 29 Dec 2020 08:16:11 -0000 On 2020-Dec-28, at 17:02, bob prohaska wrote: > On Mon, Dec 28, 2020 at 04:14:51PM -0800, Mark Millard wrote: >> [I get the problem as well! I report a backtrace of the failure >> and some more.] >>=20 >=20 > Relieved to see it's reproducible. =20 . . . I tried reducing the size of things to be produced via building the target based on the likes of using: 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 MALLOC_PRODUCTION=3D WITH_MALLOC_PRODUCTION=3D WITHOUT_ASSERT_DEBUG=3D WITHOUT_LLVM_ASSERTIONS=3D WITHOUT_DEBUG_FILES=3D (But the host 13 was unchanged.) It still failed, but at a different memory allocation, of a different size: r4 0x8000 32768 (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x4227d998 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x42332284 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x00da5e4c in report_bad_alloc_error () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:174 #4 0x00da61c8 in out_of_memory_new_handler() () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:187 #5 0x420f5d24 in operator new (size=3D) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:73 #6 0x00e16878 in SetBufferSize () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:131 #7 SetBuffered () at = /usr/src/contrib/llvm-project/llvm/lib/Support/raw_ostream.cpp:97 #8 0x00e17368 in write () at = /usr/src/contrib/llvm-project/llvm/lib/Support/raw_ostream.cpp:251 #9 0x00ddfe20 in operator<< () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:192 #10 operator<< () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:205 #11 printSymbolizedStackTrace () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:154 #12 0x00de163c in PrintStackTrace () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:575 #13 0x00ddf604 in RunSignalHandlers () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:67 #14 0x00de1f3c in SignalHandler () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:396 #15 0x42021db4 in handle_signal (actp=3Dactp@entry=3D0x424df7b0, = sig=3D, info=3Dinfo@entry=3D0x424df7f0, ucp=3D) at /usr/src/lib/libthr/thread/thr_sig.c:303 #16 0x420213f8 in thr_sighandler (sig=3D0, info=3D0x424df7f0, = _ucp=3D0x424df830) at /usr/src/lib/libthr/thread/thr_sig.c:246 #17 0xffffe190 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt = stack?) =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 Dec 29 10:15:24 2020 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 806404D736D for ; Tue, 29 Dec 2020 10:15:24 +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 4D4qzt5VQZz3pDJ for ; Tue, 29 Dec 2020 10:15:22 +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=1609236920; bh=yGG8x9xR0a1ZkLBgjzzUW8SUQEHxd/iO0LZNzG57eWx=; h=Subject:From:Date:To:From:Subject; b=Yr/rENcMom2hHGUKdSNkVKZiSKLCNVGeglkcN67+xZd0hIC6u0ptkRQ2dNrfE3+JoJrtOMpeXOVEfFPlQwGRo3Q4uz5K2F0BXsUlylpPMS1dVpdQzmYCffce4D9jb9YTpMVh04BknA5+eHWPs16ADXhKvTEPWjZnDNASF4kGbrm/G5K5jwwWqeX+fLCNxRYIbe3LJg2d+XVEbWEB3m8kRCqEwKtAokKMBXE247LVx1LUuKEQnqzp/JZ5ANTJVeVT1Kr5IOnG81A/aNkvu/eS07wlw54Vw4vG/PZKSN6gpAw3YSBhiqkg1p640mriHvXViG9X1oAIgayrYwMMwgbmLQ== X-YMail-OSG: 0PsbAhEVM1nphxJ3zt_qI93XV0uQEiySIu9dOwjeFkLD.vIg5wvz2_eaur1K2mA 3KrYlmsgCNn11MCwjQP6Ev0p0Hkw77U2OP5.Gc1FFLAOvaj4AyIqkuplc.uqZrPVb7ON1s_N2GnJ 5M2OEFceyEwLB2ZdtWHhBjHCh1A5NA.5_cOBpMsJwQ.pXaguw1cEAL7VvE200h.G2.ttecL2LZCe glCE3TSYniwcGqY3ghYw9031sJL3yUG0j95dXDik7S5S4vfNq8DNsvol6ga69Q1L4PPMoWkwgZ2m ZUL.wE_RauPb1OWj2RMAptp9EmexCQw0CvUonCOQN.YbOPebyQH8R0m1vcDoOPgNOLOMwbGExulV wsJ5ZVSI_XFbVye1oBV4zd9G5.Dzb.eH.WABYl_psA72bMuzf7O_QbIZJ9UxdYky1WlFDC37fP8E qpaIqX8HoV3rwaySES6XpapkfP3Tu0iWl623rPI7vRkc_BV.Jhd5pm_VHQmAwe.gEg4mRHsjAey1 NG9GUP_sRl8w9wKTkgH.avFxRcf2XvoMonZb00oHWWqUCHCZIT0YNc23tSGuYAG5kHb0VPEg_g60 9R0MNwsDY0Wa3EPFVMzY5uYamGz4Lx3DVfTAvqt7_mMUX_nQkaF648hXXkmODbjSpezEg1bMj2Gy 2vMIAdRtYxgbdnAJkRMB222Qy.cljezi.idgZsmL3zMEmpF7eyQnt9VG3e6MCO5ncrDKvQd3uEit nhJEwANTz7mh1QFkk0u987Zb_T.y09KB44DdowlZSSx2PS3h2hU9mZZsFLxV4KeuI5kJ1qkeFRtl yy59.kXYzpgBk7SIEnC8.PW8xptE_FeqYb9yXMfc_NMSutnRqvNILwbMiDFMK.elp4S8g6MgLJBl .iFRDvWVdNNxuILKzPiqhM_9lZGm7sS_CXqsT6OsDHtPiLFXIkP36UtdtfHGEwl5_TjpU4nBFWnK W6RRhmDis9VJRZHKW6fP1wRs9g9SCKv2BRPmaO.lazIg0dAviz89x2CYuj5Xp7121_W2QeFBLsRu UGcMSDj3Fhdk6NZnpSYFP9wzQcoIaYXH7TH65I7uNL2QZTSFe0Jjr1OR1UGdrGhGtrrpAsYX0q7E 4bLW4IEfx8IdTjYkG87kXyU3o1AUCTn7sZk9ZRwRyhLLKDRnSWsHYKMeyxgW0vuKcuHBJlVB1y6z hMa9hVvphlF6CeJuH8PgVhcXcxUBfQgUPHORDhxMSsFRHhcDq7b7_oFt07o9QSSLmV139hrfRTtZ .bgMpJ7V96njJfkw7LiLFl0_KV9XwPpY_eAwxntS1qnDFxblQtggUMRS8StNT1EQ0VQrZ7WiTukJ Qe7i6TvUxZcUJqO8jFKcZwL65Nd65vZh5d0QSQZTEjbb1KvCYstNAJ03WbXCxHV64VJE8RAZagQ8 nAcxEqFflaLgdz7bOyajCmgvo.DxFlyOzKkUk67cUCjZ_gk8xJmX6xvtLL9iZEjKpdnMjuw4Gdh. lKT1PIfBe3u7hLT3IMgQhp_sO.x1HFUXjE_VnhKDySCEKXv88q3bvHB0M4UYZdfqwG5RZ5miec_p EfotvROJ2G16fAhfRZscPICD6Vzg4CiPtpbmIEf0fEeSRXGLYQG5G9.1YI40wtCSiwOf8da_SzUn nAKp.oQn0NBYwmrlTavuo0EGDRJszRN1fHX6ASVErhrRZQN7r9lEOdosefLT4MPyJLMBGliI2wxq 10OIFw.cW4UOgrFKnjHeoSDQqhSeIXTh1t.aU0ywX66VFj.yT1KeVCyoe6kYWziPHJ87eC59XeDk odZMw28DU6JixfKrpfADYVJsn9BLCh8C_t5_k2lwoWKZIF6bZRzeqNe9J4zdxM5HI7e4V.0yg0gT 17clH77WhXsSrpHKu_TXtsWufpksgkjvODtds76yKeBXaQDlkFRwKUZjXNv6JHNqRAwzFO6IthnR nOo0AqW.lBWFZKpIkKCacWZxz.L0J9Z1kRxwShMfdbzvqiGxo1lngVAQNMkVuD2K89U_ydYMdOpP ztxmw5sF_aS4PjU1nm6EqDEDn0eX9.PCXBNs.7.fIv_291dDSOnCK125jlM8sCd8aUFupJRP_YX3 5opMFjUaEFf22U.52hAfrNZIX.O0s3VJel5VcmqQqbTY66xqQ4cT3XThEPV0m6vD3cyyKpeV9ySR rlRXTO8Gdq4f0zMpLK1xe33Yt_5qa_URCv0THn79.IHHzbMNATNb1O1KFiAIrMkc2.N16wFHW_bm LIuo0oXNUiZ8Rg6oy0891BDP6bTdFugESZ8S5ew39alASgO392_OwgsXM4_Q2TZda0O2UEVSD8q_ VfdcDCZDNsKmq19__s_DFxkYRnSOJrjcurZFlXr05OABpIBm4fGzOeL10xq7uLsawdRr7nq7o89f 4YR9PxpVTFzdIyYyMGp8vUMPRQQsWIWUjCLcM7S95aZZlb6Q0mkAwfREYJsO7rgVBFDGFmNuEabA B68vQbmCIlGrFJVl5MpZWXNOiAg4LAgQGF0GIx45wRUvP17qeo3HuroLBiasSzdDrOHdzaGWh89V uZr.PL992naU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 29 Dec 2020 10:15:20 +0000 Received: by smtp417.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d9f3f66c1bde1257f071d85302513532; Tue, 29 Dec 2020 10:15:16 +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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> Date: Tue, 29 Dec 2020 02:15:14 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> References: <20201228044840.GA28380@www.zefox.net> <20201228185622.GB28380@www.zefox.net> <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D4qzt5VQZz3pDJ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.17 / 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]; 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)[]; NEURAL_SPAM_SHORT(0.33)[0.327]; 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: Tue, 29 Dec 2020 10:15:24 -0000 On 2020-Dec-29, at 00:16, Mark Millard wrote: > On 2020-Dec-28, at 17:02, bob prohaska wrote: >=20 >> On Mon, Dec 28, 2020 at 04:14:51PM -0800, Mark Millard wrote: >>> [I get the problem as well! I report a backtrace of the failure >>> and some more.] >>>=20 >>=20 >> Relieved to see it's reproducible. =20 > . . . >=20 > I tried reducing the size of things to be produced via building > the target based on the likes of using: >=20 > 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 > MALLOC_PRODUCTION=3D > WITH_MALLOC_PRODUCTION=3D > WITHOUT_ASSERT_DEBUG=3D > WITHOUT_LLVM_ASSERTIONS=3D > WITHOUT_DEBUG_FILES=3D >=20 > (But the host 13 was unchanged.) >=20 > It still failed, but at a different memory allocation, of a > different size: >=20 > r4 0x8000 32768 >=20 > (gdb) bt > #0 thr_kill () at thr_kill.S:4 > #1 0x4227d998 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x42332284 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 > #3 0x00da5e4c in report_bad_alloc_error () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:174 > #4 0x00da61c8 in out_of_memory_new_handler() () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:187 > #5 0x420f5d24 in operator new (size=3D) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:73 > #6 0x00e16878 in SetBufferSize () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:131 > #7 SetBuffered () at = /usr/src/contrib/llvm-project/llvm/lib/Support/raw_ostream.cpp:97 > #8 0x00e17368 in write () at = /usr/src/contrib/llvm-project/llvm/lib/Support/raw_ostream.cpp:251 > #9 0x00ddfe20 in operator<< () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:192 > #10 operator<< () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:205 > #11 printSymbolizedStackTrace () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:154 > #12 0x00de163c in PrintStackTrace () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:575 > #13 0x00ddf604 in RunSignalHandlers () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:67 > #14 0x00de1f3c in SignalHandler () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:396 > #15 0x42021db4 in handle_signal (actp=3Dactp@entry=3D0x424df7b0, = sig=3D, info=3Dinfo@entry=3D0x424df7f0, ucp=3D) at /usr/src/lib/libthr/thread/thr_sig.c:303 > #16 0x420213f8 in thr_sighandler (sig=3D0, info=3D0x424df7f0, = _ucp=3D0x424df830) at /usr/src/lib/libthr/thread/thr_sig.c:246 > #17 0xffffe190 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt = stack?) Updating the host 13 made no significant difference in behavior. Using: time -l /usr/bin/ld --eh-frame-hdr -Bstatic -o clang /usr/lib/crt1.o = /usr/lib/crti.o /usr/lib/crtbeginT.o = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legac= y/usr/lib = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libz = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libexecinfo = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libelf = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/ncurses/ncursesw = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libthr -L/usr/lib --gc-sections cc1_main.o cc1as_main.o = cc1gen_reproducer_main.o driver.o = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libclang/libclang.a = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libllvm/libllvm.a -lz -lexecinfo -lelf -lncursesw -lpthread = -legacy -lc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/crtend.o = /usr/lib/crtn.o it reported after the failure output (an example): time: command terminated abnormally 26.59 real 9.40 user 12.48 sys 2052032 maximum resident set size 21793 average shared memory size 218 average unshared data size 127 average unshared stack size 703238 page reclaims 0 page faults 0 swaps 55 block input operations 3104 block output operations 0 messages sent 0 messages received 1 signals received 41126 voluntary context switches 447 involuntary context switches where looking up getrusage reports that: ru_maxrss the maximum resident set size utilized (in kilobytes). which means: 44.0625 MiByte below 2 GiBytes for the resident set. Adding --threads=3D1 made little difference: time: command terminated abnormally 28.84 real 9.28 user 12.78 sys 2065016 maximum resident set size 21872 average shared memory size 219 average unshared data size 127 average unshared stack size 709661 page reclaims 0 page faults 0 swaps 48 block input operations 3050 block output operations 0 messages sent 0 messages received 1 signals received 36717 voluntary context switches 114 involuntary context switches Abort trap =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 Dec 29 11:41:22 2020 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 832D14B9F79 for ; Tue, 29 Dec 2020 11:41:22 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from vanadio.schema31.it (vanadio.schema31.it [62.77.63.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vanadio.pomona.schema31.it", Issuer "vanadio.pomona.schema31.it" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4sv473bgz3vRx for ; Tue, 29 Dec 2020 11:41:20 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from smtp.schema31.it (localhost [127.0.0.1]) by vanadio.pomona.schema31.it (8.15.2/8.15.2) with ESMTP id 0BTBfBAh003904 for ; Tue, 29 Dec 2020 12:41:11 +0100 (CET) (envelope-from abrancatelli@schema31.it) MIME-Version: 1.0 Date: Tue, 29 Dec 2020 12:41:06 +0100 From: Andrea Brancatelli To: freebsd-arm@freebsd.org Subject: FreeBSD aarch64 on Apple M1 VM Organization: Schema31 s.r.l. Message-ID: <2f86ff63fc2706a594430a3c27845ac7@schema31.it> X-Sender: abrancatelli@schema31.it User-Agent: Roundcube Webmail/1.3.15 X-Rspamd-Queue-Id: 4D4sv473bgz3vRx X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[62.77.63.157:from]; R_DKIM_ALLOW(-0.20)[schema31.it:s=gCloud]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:62.77.63.156/28]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; SPAMHAUS_ZRD(0.00)[62.77.63.157:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[schema31.it:+]; DMARC_POLICY_ALLOW(-0.50)[schema31.it,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:20746, ipnet:62.77.32.0/19, country:IT]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Tue, 29 Dec 2020 11:41:22 -0000 Hello everybody, I'm not 100% sure this is the right place to as, in case please point me toward the correct place... (/dev/toilet :-) ) I was trying to run FreeBSD aarch64 in a Parallel Desktop VM on a Apple M1 Minimacbut wasn't able to install it. I tried different ISOs with different results: * FreeBSD-12.2-STABLE-arm64-aarch64-20201203-r368289-bootonly.iso * FreeBSD-12.2-STABLE-arm64-aarch64-20201224-r368787-bootonly.iso * FreeBSD-13.0-CURRENT-arm64-aarch64-20201224-3cc0c0d66a0-255241-bootonly.iso FreeBSD 12.2 boots but hangs ad "Mounting local filesystems" (see attached screenshot). FreeBSD 13.0 just shows a white block in the upper left corner but doesn't boot. I tried to fiddle with some settings of the VM with no particular results. Do you have any troubleshooting suggestion? Thanks -- Andrea Brancatelli From owner-freebsd-arm@freebsd.org Tue Dec 29 11:46:28 2020 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 97EDB4BA821 for ; Tue, 29 Dec 2020 11:46:28 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) (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 "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4t0z3nxKz3vfw for ; Tue, 29 Dec 2020 11:46:27 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Tue, 29 Dec 2020 11:46:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1609242379; bh=T4V8CATdV1BrbTDUO6MkktX8Vms42agdzpVu73BIdb8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=W710fgZHHjyDu+o5fMA1uYAlB2glur0hmauXB4LSePnzhiUmody5GPC+QJyqKDh6t yvbqGuABTeVunv/yQwU/vWODAAc4YYkA5Kv5CFX8XadjN/a8Dpr5zCJ2H3/HR5430r 5h2yKXrmcODQ4Y/SX8X94LiwCJT3z92Yza9aFhOg= To: Andrea Brancatelli From: Dan Kotowski Cc: freebsd-arm@freebsd.org Reply-To: Dan Kotowski Subject: Re: FreeBSD aarch64 on Apple M1 VM Message-ID: In-Reply-To: <2f86ff63fc2706a594430a3c27845ac7@schema31.it> References: <2f86ff63fc2706a594430a3c27845ac7@schema31.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4D4t0z3nxKz3vfw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=W710fgZH; dmarc=pass (policy=none) header.from=a9development.com; spf=none (mx1.freebsd.org: domain of dan.kotowski@a9development.com has no SPF policy when checking 185.70.40.136) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.80 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_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]; SPAMHAUS_ZRD(0.00)[185.70.40.136:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[185.70.40.136:from]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.136:from] 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, 29 Dec 2020 11:46:28 -0000 > Hello everybody, > > I'm not 100% sure this is the right place to as, in case please point me > > toward the correct place... (/dev/toilet :-) ) > > I was trying to run FreeBSD aarch64 in a Parallel Desktop VM on a Apple > > M1 Minimacbut wasn't able to install it. > > I tried different ISOs with different results: > > * FreeBSD-12.2-STABLE-arm64-aarch64-20201203-r368289-bootonly.iso > > * FreeBSD-12.2-STABLE-arm64-aarch64-20201224-r368787-bootonly.iso > > * > > FreeBSD-13.0-CURRENT-arm64-aarch64-20201224-3cc0c0d66a0-255241-bootonly.i= so > > FreeBSD 12.2 boots but hangs ad "Mounting local filesystems" (see > > attached screenshot). > > FreeBSD 13.0 just shows a white block in the upper left corner but > > doesn't boot. > > I tried to fiddle with some settings of the VM with no particular > > results. > > Do you have any troubleshooting suggestion? Let's focus on 13-CURRENT. Could you do a verbose boot and share the output? Also the lists stripped your attachments, so there's not much to see :( --Dan Kotowski From owner-freebsd-arm@freebsd.org Tue Dec 29 12:06:52 2020 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 546054BBBC7 for ; Tue, 29 Dec 2020 12:06:52 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from stricnina.schema31.it (stricnina.schema31.it [IPv6:2001:470:28:12b::99]) (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 "stricnina.roma.schema31.it", Issuer "stricnina.roma.schema31.it" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4tSW1ggfz4RQX for ; Tue, 29 Dec 2020 12:06:50 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from smtp.schema31.it (localhost [127.0.0.1]) by stricnina.roma.schema31.it (8.15.2/8.15.2) with ESMTP id 0BTC6Y5n083185; Tue, 29 Dec 2020 13:06:34 +0100 (CET) (envelope-from abrancatelli@schema31.it) MIME-Version: 1.0 Date: Tue, 29 Dec 2020 13:06:29 +0100 From: Andrea Brancatelli To: Dan Kotowski Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD aarch64 on Apple M1 VM Organization: Schema31 s.r.l. In-Reply-To: References: <2f86ff63fc2706a594430a3c27845ac7@schema31.it> Message-ID: <57c89092e5da03c9b7df23f6716fc359@schema31.it> X-Sender: abrancatelli@schema31.it User-Agent: Roundcube Webmail/1.3.15 X-Rspamd-Queue-Id: 4D4tSW1ggfz4RQX X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:28:12b::99:from]; R_DKIM_ALLOW(-0.20)[schema31.it:s=gCloud]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; HAS_ORG_HEADER(0.00)[]; SPAMHAUS_ZRD(0.00)[2001:470:28:12b::99:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[schema31.it:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[schema31.it,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Tue, 29 Dec 2020 12:06:52 -0000 On 2020-12-29 12:46, Dan Kotowski wrote: > Let's focus on 13-CURRENT. > > Could you do a verbose boot and share the output? > > Also the lists stripped your attachments, so there's not much to see :( > > --Dan Kotowski No problem: Here's a video of FreeBSD 12 booting and hanging: * https://www.dropbox.com/s/amdbz03o951v5hy/FreeBSD12.mov?dl=0 Here's a video of FreeBSD 13 getting stuck after bios * https://www.dropbox.com/s/txxoqkcaddq2h66/FreeBSD13.mov?dl=0 They are both from the snapshot 24 december 2020 --- Andrea Brancatelli From owner-freebsd-arm@freebsd.org Tue Dec 29 12:53:22 2020 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 4F8944BD43A for ; Tue, 29 Dec 2020 12:53:22 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4vV91kt2z4WTB for ; Tue, 29 Dec 2020 12:53:20 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Tue, 29 Dec 2020 13:53:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1609246397; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=2oQXg7AVZF5R8R4lnW1EKzKcc2FC9s7ja1cRXo9o4OM=; b=KX8GXlSW9QSysD9NFt9DQMuEsqt9YUlIjWzSmH9IcCpXZ6HXDS717OYY+BUonXjWLzv3Nh w3w+780F0Pymp8HoziZvy2FYq8MC4JYqi4eCbf2gixtl2sy1SntCf64r5krZPngM64ZUUu i5OC3omDdO7twRg+tqjJA/f+kFG5aMoE09BmLs7CZZunzAUiKLYb7sEvNMvD6/6uuGFnty 3sjhG8j4QzweVW1hIrIzKO5mE1iFWEOeImnZzd/kF8y6PrEh+mBmXTjOkq03iRZfbDDS8y yZn5aVEOj4bUvAWnfcMBS+8nrFg+1a5zvasPz8PzQlLawweZaKrQqzRlyk88zA== From: Ronald Klop To: Andrea Brancatelli via freebsd-arm , freebsd-arm@freebsd.org Message-ID: <1465195361.7086.1609246396015@localhost> In-Reply-To: <2f86ff63fc2706a594430a3c27845ac7@schema31.it> Subject: Re: FreeBSD aarch64 on Apple M1 VM MIME-Version: 1.0 X-Mailer: Realworks (538.18.299c962eae7) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4D4vV91kt2z4WTB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=KX8GXlSW; dmarc=pass (policy=none) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[194.109.157.24:from]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 29 Dec 2020 12:53:22 -0000 Van: Andrea Brancatelli via freebsd-arm Datum: 29 december 2020 12:41 Aan: freebsd-arm@freebsd.org Onderwerp: FreeBSD aarch64 on Apple M1 VM > > > Hello everybody, > > I'm not 100% sure this is the right place to as, in case please point me > toward the correct place... (/dev/toilet :-) ) > > I was trying to run FreeBSD aarch64 in a Parallel Desktop VM on a Apple > M1 Minimacbut wasn't able to install it. > > I tried different ISOs with different results: > > * FreeBSD-12.2-STABLE-arm64-aarch64-20201203-r368289-bootonly.iso > * FreeBSD-12.2-STABLE-arm64-aarch64-20201224-r368787-bootonly.iso > * > FreeBSD-13.0-CURRENT-arm64-aarch64-20201224-3cc0c0d66a0-255241-bootonly.iso > > FreeBSD 12.2 boots but hangs ad "Mounting local filesystems" (see > attached screenshot). > > FreeBSD 13.0 just shows a white block in the upper left corner but > doesn't boot. > > I tried to fiddle with some settings of the VM with no particular > results. > > Do you have any troubleshooting suggestion? > > Thanks > > -- > > Andrea Brancatelli > _______________________________________________ > 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" > > > > 12.2 gets quite far. In 12.2 type ctrl-t while it hangs to see what it is doing or what it is waiting for. And post the outcome here. Regards, Ronald. From owner-freebsd-arm@freebsd.org Tue Dec 29 13:10:50 2020 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 E7D874BDF70 for ; Tue, 29 Dec 2020 13:10:50 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from vanadio.schema31.it (vanadio.schema31.it [62.77.63.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vanadio.pomona.schema31.it", Issuer "vanadio.pomona.schema31.it" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4vtL0f1mz4XFt for ; Tue, 29 Dec 2020 13:10:49 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from smtp.schema31.it (localhost [127.0.0.1]) by vanadio.pomona.schema31.it (8.15.2/8.15.2) with ESMTP id 0BTDAker015016; Tue, 29 Dec 2020 14:10:46 +0100 (CET) (envelope-from abrancatelli@schema31.it) MIME-Version: 1.0 Date: Tue, 29 Dec 2020 14:10:41 +0100 From: Andrea Brancatelli To: Ronald Klop Cc: Andrea Brancatelli via freebsd-arm Subject: Re: FreeBSD aarch64 on Apple M1 VM Organization: Schema31 s.r.l. In-Reply-To: <1465195361.7086.1609246396015@localhost> References: <1465195361.7086.1609246396015@localhost> Message-ID: <1b9c66034cab498f30c03bc81d2d52a0@schema31.it> X-Sender: abrancatelli@schema31.it User-Agent: Roundcube Webmail/1.3.15 X-Rspamd-Queue-Id: 4D4vtL0f1mz4XFt X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[62.77.63.157:from]; R_DKIM_ALLOW(-0.20)[schema31.it:s=gCloud]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:62.77.63.156/28]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; HAS_ORG_HEADER(0.00)[]; SPAMHAUS_ZRD(0.00)[62.77.63.157:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[schema31.it:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[schema31.it,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:20746, ipnet:62.77.32.0/19, country:IT]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Tue, 29 Dec 2020 13:10:51 -0000 On 2020-12-29 13:53, Ronald Klop wrote: > 12.2 gets quite far. > In 12.2 type ctrl-t while it hangs to see what it is doing or what it is waiting for. > And post the outcome here. Hello Ronald. I did a new video pressing Control-T a couple of time before it hangs. When it hangs, well, it hangs so it stops responding. https://www.dropbox.com/s/ic5nf4q0dzcd04k/FreeBSD12%20-%20ControlT%20just%20before%20it%20hangs.mov?dl=0 In a previous session I also tried standard Alt-F1 and whatever but the machine seems to be totally stuck. I tried also a verbose boot, but my general perception is that it hangs when the installation stuff starts. I cannot remember what's the step just after "mounting file systems"... --- Andrea Brancatelli From owner-freebsd-arm@freebsd.org Tue Dec 29 13:13:23 2020 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 404964BDFF5 for ; Tue, 29 Dec 2020 13:13:23 +0000 (UTC) (envelope-from sv@ulstu.ru) Received: from mr0.ulstu.ru (mr5.ulstu.ru [79.132.103.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4vxF6BD2z4XZT for ; Tue, 29 Dec 2020 13:13:21 +0000 (UTC) (envelope-from sv@ulstu.ru) Received: from [192.168.0.22] (unknown [109.197.193.192]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mr0.ulstu.ru (Postfix) with ESMTPSA id 2180F42D07; Tue, 29 Dec 2020 13:13:14 +0000 (UTC) Reply-To: sv@ulstu.ru Subject: Re: FreeBSD aarch64 on Apple M1 VM To: Andrea Brancatelli References: <2f86ff63fc2706a594430a3c27845ac7@schema31.it> <57c89092e5da03c9b7df23f6716fc359@schema31.it> From: Serge Volkov Organization: SISADMINOV.NET Cc: freebsd-arm@freebsd.org Message-ID: <2acc461a-22d0-1728-2ab9-a766b85ab66f@ulstu.ru> Date: Tue, 29 Dec 2020 17:13:10 +0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <57c89092e5da03c9b7df23f6716fc359@schema31.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: ru Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4D4vxF6BD2z4XZT X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.90 / 15.00]; HAS_REPLYTO(0.00)[sv@ulstu.ru]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:79.132.103.0/26]; REPLYTO_ADDR_EQ_FROM(0.00)[]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[ulstu.ru:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[ulstu.ru,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[79.132.103.18:from]; ASN(0.00)[asn:43782, ipnet:79.132.96.0/20, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[ulstu.ru:s=default]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[79.132.103.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; 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, 29 Dec 2020 13:13:23 -0000 I have the same issue on Baikal M1000 arm64 SoC. This is not a virtual machine. FreeBSD 12.2 GENERIC boots, but FreeBSD 13 GENERIC does not. FreeBSD 13 just shows a white cursor in the upper left corner. I am using a monitor with HDMI connection. At first I thought it was an HDMI problem. But now I don't know what the problem is. 29.12.2020 16:06, Andrea Brancatelli via freebsd-arm пишет: > On 2020-12-29 12:46, Dan Kotowski wrote: > >> Let's focus on 13-CURRENT. >> >> Could you do a verbose boot and share the output? >> >> Also the lists stripped your attachments, so there's not much to see :( >> >> --Dan Kotowski > > No problem: > > Here's a video of FreeBSD 12 booting and hanging: > > * https://www.dropbox.com/s/amdbz03o951v5hy/FreeBSD12.mov?dl=0 > > Here's a video of FreeBSD 13 getting stuck after bios > > * https://www.dropbox.com/s/txxoqkcaddq2h66/FreeBSD13.mov?dl=0 > > They are both from the snapshot 24 december 2020 > > --- > > Andrea Brancatelli > _______________________________________________ > 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" > -- With best regards, Serge Volkov, http://www.ulbsd.ru From owner-freebsd-arm@freebsd.org Tue Dec 29 14:40:36 2020 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 751B94C135C for ; Tue, 29 Dec 2020 14:40:36 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from stricnina.schema31.it (stricnina.schema31.it [IPv6:2001:470:28:12b::99]) (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 "stricnina.roma.schema31.it", Issuer "stricnina.roma.schema31.it" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4xsv08J6z4fGS for ; Tue, 29 Dec 2020 14:40:34 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from smtp.schema31.it (localhost [127.0.0.1]) by stricnina.roma.schema31.it (8.15.2/8.15.2) with ESMTP id 0BTEeWn2002336; Tue, 29 Dec 2020 15:40:32 +0100 (CET) (envelope-from abrancatelli@schema31.it) MIME-Version: 1.0 Date: Tue, 29 Dec 2020 15:40:26 +0100 From: Andrea Brancatelli To: Ronald Klop Cc: Andrea Brancatelli via freebsd-arm Subject: Re: FreeBSD aarch64 on Apple M1 VM Organization: Schema31 s.r.l. In-Reply-To: <1465195361.7086.1609246396015@localhost> References: <1465195361.7086.1609246396015@localhost> Message-ID: X-Sender: abrancatelli@schema31.it User-Agent: Roundcube Webmail/1.3.15 X-Rspamd-Queue-Id: 4D4xsv08J6z4fGS X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:28:12b::99:from]; R_DKIM_ALLOW(-0.20)[schema31.it:s=gCloud]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; HAS_ORG_HEADER(0.00)[]; SPAMHAUS_ZRD(0.00)[2001:470:28:12b::99:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[schema31.it:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[schema31.it,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Tue, 29 Dec 2020 14:40:36 -0000 On 2020-12-29 13:53, Ronald Klop wrote: > 12.2 gets quite far. > In 12.2 type ctrl-t while it hangs to see what it is doing or what it is waiting for. > And post the outcome here. > > Regards, > Ronald. > _______________________________________________ > 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" Lowering the Virtual CPUs to 2 (it was 4 before) and increasing memory from 2G to 5G got me to this point: https://www.dropbox.com/s/84m48sgdguh6tac/Schermata%202020-12-29%20alle%2015.33.45.png?dl=0 It's not hung now, it's just stuck into route since 1100 seconds... I'll wait some more but I have some doubts it will go on... --- Andrea Brancatelli From owner-freebsd-arm@freebsd.org Tue Dec 29 14:47:28 2020 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 986F24C1740 for ; Tue, 29 Dec 2020 14:47:28 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from stricnina.schema31.it (stricnina.schema31.it [IPv6:2001:470:28:12b::99]) (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 "stricnina.roma.schema31.it", Issuer "stricnina.roma.schema31.it" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4y1q2MBhz4fjd for ; Tue, 29 Dec 2020 14:47:26 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from smtp.schema31.it (localhost [127.0.0.1]) by stricnina.roma.schema31.it (8.15.2/8.15.2) with ESMTP id 0BTElP2i003215 for ; Tue, 29 Dec 2020 15:47:25 +0100 (CET) (envelope-from abrancatelli@schema31.it) MIME-Version: 1.0 Date: Tue, 29 Dec 2020 15:47:19 +0100 From: Andrea Brancatelli To: freebsd-arm@freebsd.org Subject: [Partially Solved] FreeBSD aarch64 on Apple M1 VM Organization: Schema31 s.r.l. In-Reply-To: References: <1465195361.7086.1609246396015@localhost> Message-ID: <3e4afefe6a004bd2730adc42ea58df6b@schema31.it> X-Sender: abrancatelli@schema31.it User-Agent: Roundcube Webmail/1.3.15 X-Rspamd-Queue-Id: 4D4y1q2MBhz4fjd X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:28:12b::99:from]; R_DKIM_ALLOW(-0.20)[schema31.it:s=gCloud]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; SPAMHAUS_ZRD(0.00)[2001:470:28:12b::99:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[schema31.it:+]; DMARC_POLICY_ALLOW(-0.50)[schema31.it,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Tue, 29 Dec 2020 14:47:28 -0000 Hello everybody. I was able to correctly start the installer with 1 CPU and 4 GB Ram. So the problem seems to be related to multi-core support. Now I can't see any network interface... but that's another story... I'll do some investigations. --- Andrea Brancatelli From owner-freebsd-arm@freebsd.org Tue Dec 29 15:44:50 2020 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 BB61E4C3077 for ; Tue, 29 Dec 2020 15:44:50 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from stricnina.schema31.it (stricnina.schema31.it [IPv6:2001:470:28:12b::99]) (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 "stricnina.roma.schema31.it", Issuer "stricnina.roma.schema31.it" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4zJ13j99z4kP4 for ; Tue, 29 Dec 2020 15:44:49 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from smtp.schema31.it (localhost [127.0.0.1]) by stricnina.roma.schema31.it (8.15.2/8.15.2) with ESMTP id 0BTFikPv010413 for ; Tue, 29 Dec 2020 16:44:46 +0100 (CET) (envelope-from abrancatelli@schema31.it) MIME-Version: 1.0 Date: Tue, 29 Dec 2020 16:44:41 +0100 From: Andrea Brancatelli To: freebsd-arm@freebsd.org Subject: VirtIO-Net not correctly handled Organization: Schema31 s.r.l. Message-ID: <43d2a4466c791c6d0d31b099be57ee87@schema31.it> X-Sender: abrancatelli@schema31.it User-Agent: Roundcube Webmail/1.3.15 X-Rspamd-Queue-Id: 4D4zJ13j99z4kP4 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.72 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:28:12b::99:from]; R_DKIM_ALLOW(-0.20)[schema31.it:s=gCloud]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; 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]; HAS_ORG_HEADER(0.00)[]; SPAMHAUS_ZRD(0.00)[2001:470:28:12b::99:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[schema31.it:+]; DMARC_POLICY_ALLOW(-0.50)[schema31.it,quarantine]; NEURAL_HAM_SHORT(-0.72)[-0.723]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Tue, 29 Dec 2020 15:44:50 -0000 Hello everybody, after tuning CPU (1 cpu only) and Ram I was able to do a full install of FreeBSD 12.2 in a Parallel Desktop VM running on an Apple M1. Everything seems quite in order but I can't get the network card to work. Parallel Desktop is presenting a virtio-net card and pciconf is correctly listing it but the driver doesn't hook to it. Here you can see a screenshot of the situation: https://www.dropbox.com/s/hv6g8btjm45m0mh/Schermata%202020-12-29%20alle%2016.42.10.png?dl=0 [sorry if I keep posting screenshots but there's no console integration so I can't copy and paste...] Any suggestion on how to get it working or investigate deeper? Thanks a lot. -- Andrea Brancatelli From owner-freebsd-arm@freebsd.org Tue Dec 29 18:06:57 2020 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 886DB4C6EA4 for ; Tue, 29 Dec 2020 18:06:57 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (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 "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D52S0461qz4v7F for ; Tue, 29 Dec 2020 18:06:56 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Tue, 29 Dec 2020 18:06:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1609265213; bh=QsWh0vLfZ3X54w1Dj31sAU3k76uwBw9L2H3ChJgccM0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=BBtqG83hjIVT+jyvcVPNVMjsZ3HEpp1n65XvEYzKJJTIUJc7vxsZo16fzk1bbp78l xT2QYRKlbukQVZB9PXYnN7MgVXDv9jHsI1SlIJ8kv1L9e99Tut1V6nMNb1bSAGHkK/ qEZq5qAF4D/FVHV4KGWiJXU05ahGowa8bzl0n+hY= To: Andrea Brancatelli From: Dan Kotowski Cc: freebsd-arm@freebsd.org Reply-To: Dan Kotowski Subject: Re: VirtIO-Net not correctly handled Message-ID: In-Reply-To: <43d2a4466c791c6d0d31b099be57ee87@schema31.it> References: <43d2a4466c791c6d0d31b099be57ee87@schema31.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4D52S0461qz4v7F X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=BBtqG83h; dmarc=pass (policy=none) header.from=a9development.com; spf=none (mx1.freebsd.org: domain of dan.kotowski@a9development.com has no SPF policy when checking 185.70.40.18) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.28 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_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]; SPAMHAUS_ZRD(0.00)[185.70.40.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.48)[-0.480]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[185.70.40.18:from]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.18:from] 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, 29 Dec 2020 18:06:57 -0000 > Hello everybody, > > after tuning CPU (1 cpu only) and Ram I was able to do a full install of > > FreeBSD 12.2 in a Parallel Desktop VM running on an Apple M1. > > Everything seems quite in order but I can't get the network card to > > work. > > Parallel Desktop is presenting a virtio-net card and pciconf is > > correctly listing it but the driver doesn't hook to it. > > Here you can see a screenshot of the situation: > > https://www.dropbox.com/s/hv6g8btjm45m0mh/Schermata 2020-12-29 alle 16.42= .10.png?dl=3D0 > > [sorry if I keep posting screenshots but there's no console integration > > so I can't copy and paste...] > > Any suggestion on how to get it working or investigate deeper? What about with 13-CURRENT? There's a lot of aarch64 work going on in 13 th= at is unlikely to be backported to 12, so it'll be best to focus effort the= re. --Dan Kotowski From owner-freebsd-arm@freebsd.org Tue Dec 29 21:24:59 2020 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 EC9184CB90E for ; Tue, 29 Dec 2020 21:24:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4D56rV0QJRz3Qkd for ; Tue, 29 Dec 2020 21:24: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=1609277095; bh=N6M8DikHaEcYsCqsH0jtHOTYEPD37dDy2UARPkZ6cIb=; h=Subject:From:Date:To:From:Subject; b=SRxHSre7QzWRTmSAGBX9gNrKhX7s6hZp/Yd3KfE/u0zbVUNMM2CZ9TFQ2D95WMzv6l3qNXCGFQBr38FbXkpC+u0VvyqN5ZEPRVYyjOg3l/GrKHsj9TpvuW5q3bJX9y38MkW1f/bNidQvdPkpUAGw1DEYlfnVFIKOHnqYijdHuXl7ArToZIHyh+/4feIuCSmyvVqigTXPmWwaCWg4gI81z/XbOK3BI84dweVZECJjPbbxArWvjlrQTVTzxtJdZ2M0iaDlVEpKrELg8/AH+4Va93yCQwFDvyw6A4lt7mAics7tqLksA3HWMKk/jAWHvxXJW8twWV3zQeoc5eWEI+yIgg== X-YMail-OSG: xyX0aU8VM1mJbGKoaTXyXKJXymwPjAA5zTOUedViIFeIwtT.V0Sj0lHCXGZrFKs R4.9smOEYBhNrU52Y_NQlSOsZrIUdg9vskSFDY7dTZ5RDNStRenVB2uWTgpwPdOJr84myBLCmBkL lP71rTzc2azyp7FlxdAwdQyy5kQ3ERxokGGimcxhwfpCZhk6LhURRSQBU_iXmCVUNnJd8G01baIR b2tfwri_BB43Eke8ud26ojJFNFQDkYIMXxqc8YMxDhsYZivyIdb3XGs9tGthLdyuvkGZ2PCjsKIz ILeEbvLo.afFKwsqi.7VWonwpyIAe8CSvK4SGKmG1Ea3fSck.RHP.IuhBOKMTd7i3uOFVKXEwb7w eh1FcCYKjkxCb9sDXFwKSRqq9slK6F2rJTNQZ0CeUhdZ5moiAOVKka3IMSSZ0qhHMtHOOTle_hCu UDz1SMWiT5lORdes.KA3AHzVb__HL9gwgY1RHeWQinL46X7gPmw6HH0_23Qz2QanSMk46DYiGoqm P5PGNuqipDUorLz0V3S4wrXF6gV8RhenC.1Y3Ra0nipFjpaGTbF92nZgY2Kr_bmBX96MdY_z1uiw IJ_es99fbftmMnkgFDV7odoRHbSM3ZW1foqadmo4_dV11obNgwPl49XGOM.6nt_uUy_qpsKwj1Yh fD1sEoV5T38Y5Ze8f.7DzRPYMqDrsPiBA5Qmw55kzYJEdi0erqEIp.c2RndMYbtIW6TrGH_lnXAX GNd0vMozXQZMNiNWJy5KdbaYDrrJEHz605SGJH0hXuLI.SsBxw8aIEirXFJVm_LKYlzEA_iURJE9 JFFzJZmBZxHEc.Mu08hf3x7kD72h.NA1cNF_2GGFF66gefFvKohuS2K2jUmWDkU4t.qpno9Q6nmx FNoHZk4EVD04oJTgiy6TPtC7raqrseYlVj4Lv2alDDwXxSJKNxJWk1RcJPe.0Kr0A6e4fl4tLBHE vhQXewOTlhO2C3GJOiewbZZVfIVomDu.WgPd6PJpBePSTvruQGFUqiKcTGBlJIL2v0SoyXDAXvij YMj23PZJL57bPi.6u_8BMZ8KMSRgCEY0smp_6ghSyZVLxg4Tldpfg4nsaImjzCk6Ij1XqFVQ4snb 8Y5WTssseSmYvmQTylZYKJyhjXhmLNkTC.SRA32ScdyTZ4Zzp8kMKb7TytdPO9vFfTmdi2nvWkk8 PlagLn80BXzIY2gsDGGIvtXSx3gcBBIGah3VqGlOEQODE_GiBuEYFvuk2.gH_Xlpz3XN0Aai8jKy hOnWn2bb7rFM3H86XA8CUJ.CkXhT472TKPGd6L5ny03neNz6RnJ18PpbtS7Vb4Ei_67XJf9CTXQA 77ZMBmsWYYdT7fqIi9M1xkcztwfCMme52GQIpO9b0RU3qqEWE9P0cc1O8kc.E3R30C5mZiJyujvF MIEcsCaglzCeeOb8w3CpIb5PYp.FVmmc4EV1v_M4CXV6a7fxgEF6PFUxwsdzNGgVDW1lNx6aYk15 8RMFCIoXGflJXvjipFUsWJAdbt6LffHuohGSI1pnmTXWfaiLBOFXLjKOOxdIIWWr3Vy2yglfss1s mF5JLHBJ9H_8PBKSZEfgySsn8rFIsohLCRBO3x7CwHVjGiLEpxMC4Ifh83I_emJJkZS3BAwY5An8 ChaM9zNsD1zFVqj0pxOJEnlM23QeuaF0wWpg2_wgtMge3LY5aP66y2py7BHacz5bFfwrGE_zwcQt TyzbtgUF7aKlv0jvnhTSu6lnAa334KiyMncuX.kv.FooxcgaT9_KiS5uej4EjuKD6iKsIwtzpt3s 66_Q9Xy8tNKNyFjr4qxUYjXKt4VOPxGzNkqCAWkhQjbKWSdSW8jtc2cU18kDAOxpUJHEy_EXASdb mBobkmJbnKpvnGT1bOIBpqEFzgJGT7uTfmvPCAzcbTRwa7kSMLI9UL5nRTAh22T1rbqfPPH7QAr. wZV_VBD3tC0biIIo2aLQr32wqZGIHjLnyy4B5YNchav7LhPIoO4yNh3MWSgxTcykRcAnv5RTKO8C XjDz2kPGqYCSOodNMHeBlH0EfxCpDrvILLDNLc1ljQmHNPmoffK2SH6oyH1SAOLtKVV3JabgDTPj A7Be0qw5hzRDwLuJIqqTiOQ.ZV5hvyHTnDsgzTZg_2ovMwtEI92nsqjP_SrJJlhFciWERkIENi9t pPlmKmoTmrTv308QsnBHutgb47OAZJbpixkXudPciOOuuZ8HZ.uZ_NaHrR0tyVQLWKt.dqx_xAJ4 bagIlHLMILDqsTxE0aMVmMyVEc80xfVtflP_1qtyZlekBN1CqHg1tXFdYY3egfDRK6Ib39Vdnx3o EKhY6Z34BIKEvFn8AY_0o5l8M0U2LGm84l898U5QJcLxagqMwCNUiBKFzduGPGN.MNe6saTpk2pT N1mQpSDc73Ada4oZ94piqGicEWk5fd68x0ES0sRGONTuGweaverine.uTzYBo6qr1MnLd7jdlJ2e BwnY.KUljMWbqKRR4tReuv5ML6JJ22Mev_1xi3znvLaXN4AITJzFMGm8tQLtTs0L_Q4iIkcPoY.4 JXxg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 29 Dec 2020 21:24:55 +0000 Received: by smtp409.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 142f1cbe6aacd1ece5c620fe482e11a0; Tue, 29 Dec 2020 21:24:50 +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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> Date: Tue, 29 Dec 2020 13:24:49 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201228044840.GA28380@www.zefox.net> <20201228185622.GB28380@www.zefox.net> <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D56rV0QJRz3Qkd 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.69.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)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.205:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.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: Tue, 29 Dec 2020 21:25:00 -0000 On 2020-Dec-29, at 02:15, Mark Millard wrote: > On 2020-Dec-29, at 00:16, Mark Millard wrote: >=20 >> On 2020-Dec-28, at 17:02, bob prohaska wrote: >>=20 >>> On Mon, Dec 28, 2020 at 04:14:51PM -0800, Mark Millard wrote: >>>> [I get the problem as well! I report a backtrace of the failure >>>> and some more.] >>>>=20 >>>=20 >>> Relieved to see it's reproducible. =20 >> . . . >>=20 >> I tried reducing the size of things to be produced via building >> the target based on the likes of using: >>=20 >> 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 >> MALLOC_PRODUCTION=3D >> WITH_MALLOC_PRODUCTION=3D >> WITHOUT_ASSERT_DEBUG=3D >> WITHOUT_LLVM_ASSERTIONS=3D >> WITHOUT_DEBUG_FILES=3D >>=20 >> (But the host 13 was unchanged.) >>=20 >> It still failed, but at a different memory allocation, of a >> different size: >>=20 >> r4 0x8000 32768 >>=20 >> (gdb) bt >> #0 thr_kill () at thr_kill.S:4 >> #1 0x4227d998 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 >> #2 0x42332284 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >> #3 0x00da5e4c in report_bad_alloc_error () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:174 >> #4 0x00da61c8 in out_of_memory_new_handler() () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:187 >> #5 0x420f5d24 in operator new (size=3D) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:73 >> #6 0x00e16878 in SetBufferSize () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:131 >> #7 SetBuffered () at = /usr/src/contrib/llvm-project/llvm/lib/Support/raw_ostream.cpp:97 >> #8 0x00e17368 in write () at = /usr/src/contrib/llvm-project/llvm/lib/Support/raw_ostream.cpp:251 >> #9 0x00ddfe20 in operator<< () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:192 >> #10 operator<< () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:205 >> #11 printSymbolizedStackTrace () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:154 >> #12 0x00de163c in PrintStackTrace () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:575 >> #13 0x00ddf604 in RunSignalHandlers () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:67 >> #14 0x00de1f3c in SignalHandler () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:396 >> #15 0x42021db4 in handle_signal (actp=3Dactp@entry=3D0x424df7b0, = sig=3D, info=3Dinfo@entry=3D0x424df7f0, ucp=3D) at /usr/src/lib/libthr/thread/thr_sig.c:303 >> #16 0x420213f8 in thr_sighandler (sig=3D0, info=3D0x424df7f0, = _ucp=3D0x424df830) at /usr/src/lib/libthr/thread/thr_sig.c:246 >> #17 0xffffe190 in ?? () >> Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >=20 >=20 > Updating the host 13 made no significant difference in > behavior. >=20 > Using: >=20 > time -l /usr/bin/ld --eh-frame-hdr -Bstatic -o clang /usr/lib/crt1.o = /usr/lib/crti.o /usr/lib/crtbeginT.o = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legac= y/usr/lib = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libz = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libexecinfo = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libelf = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/ncurses/ncursesw = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libthr -L/usr/lib --gc-sections cc1_main.o cc1as_main.o = cc1gen_reproducer_main.o driver.o = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libclang/libclang.a = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libllvm/libllvm.a -lz -lexecinfo -lelf -lncursesw -lpthread = -legacy -lc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/crtend.o = /usr/lib/crtn.o >=20 > it reported after the failure output (an example): >=20 > time: command terminated abnormally > 26.59 real 9.40 user 12.48 sys > 2052032 maximum resident set size > 21793 average shared memory size > 218 average unshared data size > 127 average unshared stack size > 703238 page reclaims > 0 page faults > 0 swaps > 55 block input operations > 3104 block output operations > 0 messages sent > 0 messages received > 1 signals received > 41126 voluntary context switches > 447 involuntary context switches >=20 > where looking up getrusage reports that: >=20 > ru_maxrss the maximum resident set size utilized (in kilobytes). >=20 > which means: 44.0625 MiByte below 2 GiBytes for the resident set. >=20 > Adding --threads=3D1 made little difference: >=20 > time: command terminated abnormally > 28.84 real 9.28 user 12.78 sys > 2065016 maximum resident set size > 21872 average shared memory size > 219 average unshared data size > 127 average unshared stack size > 709661 page reclaims > 0 page faults > 0 swaps > 48 block input operations > 3050 block output operations > 0 messages sent > 0 messages received > 1 signals received > 36717 voluntary context switches > 114 involuntary context switches > Abort trap I found another difference between how 13 is built and stable/12 is built, so I'm trying another build. The below shows what I've changed in stable/12 , but 13 eliminated even having the conditional logic, always using -O2 -pipe : # git diff | more diff --git a/share/mk/sys.mk b/share/mk/sys.mk index 9099b63a61a0..53d1e30b1d56 100644 --- a/share/mk/sys.mk +++ b/share/mk/sys.mk @@ -167,7 +167,7 @@ CFLAGS ?=3D -O .else CC ?=3D cc .if ${MACHINE_CPUARCH} =3D=3D "arm" || ${MACHINE_CPUARCH} =3D=3D "mips" -CFLAGS ?=3D -O -pipe +CFLAGS ?=3D -O2 -pipe .else CFLAGS ?=3D -O2 -pipe .endif I'll report if the use of ld to produce clang.full still fails or not. I've left the other things attempting to lead to less memory use in place. =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 Dec 29 22:27:49 2020 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 4574C4CCC9F for ; Tue, 29 Dec 2020 22:27:49 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from vanadio.schema31.it (vanadio.schema31.it [62.77.63.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vanadio.pomona.schema31.it", Issuer "vanadio.pomona.schema31.it" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D58Dz5G5Nz3kgb for ; Tue, 29 Dec 2020 22:27:47 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from smtp.schema31.it (localhost [127.0.0.1]) by vanadio.pomona.schema31.it (8.15.2/8.15.2) with ESMTP id 0BTMRaHb083572; Tue, 29 Dec 2020 23:27:36 +0100 (CET) (envelope-from abrancatelli@schema31.it) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andrea Brancatelli Mime-Version: 1.0 (1.0) Subject: Re: VirtIO-Net not correctly handled Date: Tue, 29 Dec 2020 23:27:30 +0100 Message-Id: <7849A0D0-7307-4432-B0B0-6005C7062BBA@schema31.it> References: Cc: freebsd-arm@freebsd.org In-Reply-To: To: Dan Kotowski X-Mailer: iPhone Mail (18B92) X-Rspamd-Queue-Id: 4D58Dz5G5Nz3kgb X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[62.77.63.157:from]; R_DKIM_ALLOW(-0.20)[schema31.it:s=gCloud]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:62.77.63.156/28]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[62.77.63.157:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[schema31.it:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[schema31.it,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20746, ipnet:62.77.32.0/19, country:IT]; 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, 29 Dec 2020 22:27:49 -0000 I could not find any way to get it to boot. :-( Machine on, white block upper left, nothing else happens. Inviato da iPhone > Il giorno 29 dic 2020, alle ore 19:14, Dan Kotowski ha scritto: >=20 > =EF=BB=BF >>=20 >> Hello everybody, >>=20 >> after tuning CPU (1 cpu only) and Ram I was able to do a full install of >>=20 >> FreeBSD 12.2 in a Parallel Desktop VM running on an Apple M1. >>=20 >> Everything seems quite in order but I can't get the network card to >>=20 >> work. >>=20 >> Parallel Desktop is presenting a virtio-net card and pciconf is >>=20 >> correctly listing it but the driver doesn't hook to it. >>=20 >> Here you can see a screenshot of the situation: >>=20 >> https://www.dropbox.com/s/hv6g8btjm45m0mh/Schermata 2020-12-29 alle 16.42= .10.png?dl=3D0 >>=20 >> [sorry if I keep posting screenshots but there's no console integration >>=20 >> so I can't copy and paste...] >>=20 >> Any suggestion on how to get it working or investigate deeper? >=20 > What about with 13-CURRENT? There's a lot of aarch64 work going on in 13 t= hat is unlikely to be backported to 12, so it'll be best to focus effort the= re. >=20 > --Dan Kotowski From owner-freebsd-arm@freebsd.org Tue Dec 29 22:50:15 2020 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 3187A4CD26E for ; Tue, 29 Dec 2020 22:50:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.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 4D58kr6gNvz3m0s for ; Tue, 29 Dec 2020 22:50:12 +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=1609282211; bh=jsRt+kc+9TjAaz3KC0Yp8F8xL9ayUNBpTfHQo5fVKU6=; h=Subject:From:Date:To:From:Subject; b=CxPAfaJCqpwg11FjZyLd1r0PHOfX/TWymZj1M2YuzGoMa7n7xUOA43jG5tJBUbmDBoa4+fAkmW8o/HAYeNczl7Lb8QFi3tIYYc0FD1ktf/P+8B2XNAXrrz46XtFCwvR8OmTCrbkmF4E8BRrQlXQd+rNxxZNHtW88Lyp4Oe6gbFUOxDEQEHfFFhGqhOZxS2EZk8bOjjHLf51rudbbWcYt5aVOyvucIqMVDGAhE55wCPlaks69kvpSG5oPMLUhN28vAg3ewoP6qg/T5iNSMApMGnCPoLYSzfbqxDW+ZfOH217mK4dDEgeCJUE/lM8qeysKF/MEWdZOe8Vrj/BzJ/DMXA== X-YMail-OSG: bxzqOc0VM1nq0T_Ccef1GW9WB2YO.RhkATKtmmWvY4m84RVU6MgDQm1xeeQwi7m IMbQv0V5wy7K4V.DJ.mHBnGXc34h_r0FfOHkczB_J_buiBKylTppLYXHzIDiURiRWJ3NvkpNI1uv WWNhpGXoYVgXsseM4MhRFOvbqgPzgcUwS7qzjj3VC3tXjdI9XzWi.HP7zPOx2ebftSK7rt9i76J0 LLqyAstuEx3L5bg2rK0_IjzRahMS1oN4FnkQaVa.q79sdYxoY0c5kKqtEgytln0IuAfxYDqKinNm E429MrdS5v8cveyRfASZI5i7LhM8_PA5bUe7D8jBIirdxHyC6BJkzTEx93NoIAO_b_1CQ0TSa2tT WK4BgXtOjPw1sfz.zv0T_aHHlZSGZgCawAKQBg0yHNk3KpI1xgez.ZnE_9GNGyRIvtBK_64hJtRB bmapXDToD0FEUlHw4Aa2rfiChyYXT.jcK9XeJzcjyoUDNIb0e2ekSVIo6iCaGccDF4X59m8AbLPp S.xFpuGs7s2Eg_A4ojYhswydNazOhnrtpALqh5ww7cRlqv.CkTIpFl6bEhqA1pGwEfcNlP1jjYfP 2LxBBdJNLRX6xt7j8Kt9kb3d03LfOhDJEt_H6byax7TjZA8NuWsTd3AnerRZHIujMMcDF1RbCRvN gMToJ7_ghWPQswfMlrTC9doqT8.0LheuICrSpoRs.sCp_Df2b_0wwuOPXV9klW3vkrxlscQNuoaG U3YLPJ_yjzVdApPY8M9HacnhQr_IieosWDF0j0ieqYonsoCl53xFmIaj8EA1RiGXothuXK3BFIDe w6MDEA0JXouUNWAU4145UT74Pbx8bw_wut24.26UDjOOobJ1sCRtvgvC1KjDXmLRqT6vBkGCiX.R FIRCBisVxSeXzdBzWV1XGwrWtMqjhDR_MmCUEdmyajfhrE.UpfNHAH6Co4xhC.3WufnSwTvGEyMp o0dkmGtzxK4NbNgCKoZp2CviGm9.muUWd1I4KfW3wZi7NJ8z9.6JgDBdh7.Q8wMriP.zt7w_KyTo uLbal9QvtG2EFtfy2pc_MW2xGl1vbUh7fYspMxbF.kpY17SBVAHj45TuG1470N_r5efGdmGvUCRL 26ASICs_IcqLNTidJ0_qebWSrxKZ4EIgcaWsI2gUAoLgp52bkEh7l85aZqLHXtiSsh5uAjIRjAPs nFFJnVvHGBUkMMI.j1YQlq6E2jGr1XCT7p3ciqNEIH3A7Pg0vjST0VRB.yL0wzKY_h2BFoX8gT_6 wThVh0IlbpNKyBlFZhx4rJgXd23iVYqtmYqlPOGMsy3xRw7ns2v2bgswFd.hgzUPl1Go8eiW4l4A iB9jps9ZG_rI97IR1f3ID4JzFcegFBC8PJZxFAK2ymNi8zyWJjCrXofnbaM4P3pk8EJncm3ZzacL TjFEj8.mV7Rcd004jtZFVM1jhRr_I9pCJJxGF5PVbKfvalgz_e93RNBhybrWG3Om4d5F1iZDHZzi tZbxHW_ixT4d9cfqODY.LFInkq_29o8UZDIG.efJhYKHbq30yilLYmxxnQPnB7bfdvtxOQAXkAuI mW4qvQ9pSfsnGALuQwCqnGoG9BfiWaoh07DFqoxBD3jZKohYjJlNYFHeWHlTL35HDWpYZJAbfB7s NJ6OAOxZg0Na.EpTg8ZxsOZlYBfpnGleE1hpwPd6_Mh5jFbSCqktpSNVOkNLAha4YEdJSbrx4BRR L.QrSftf1L_AvUjAtJcX17ev6EgA1WK8YloT8pzoPWBFRE0HT9ADdW_odV141Th1joirMOI_AJXx PG9Wtvi0avB3uttVuHnk2tfmUQ8dZBbvX95y9TEWhBjKY88_J0NlXEileqvDi69lKIUlcKCZ7JJS Hx4Rs24_kPXx0W.Tsf2y0WtUrhpGUAvGCEy1QYvdPDC_agDfk6N67iKmcH8DvE2IBOhMn0v0k6pr ePzV41QI15dFIcjoeySGFijh.tJsQ..Jm_TzSDpaZVXcWUltkxhhDewgPmaU.gdagI6Fxt.sL2xo x1ElKv6nTDgbpTmRr3YjmIvV1n.fIL27ne8oU9F8e5.QnUu2On_xrlFWaaet_HbGcTUy5WGTC6uU BYod78g.z8uvWHaSIjhdJ.mNfKoUO8dXG3YZ5dV4cs0JRWIc1RMj3mHvJv.m760oAr4A1zEghG8t PTSm4Kkl4_nLBAbKWoU0w7NZcZNs.AXW_fqwh7aSt1GFUrJKh.uA_SgY_nZbxF.vwJuk.8DwFadn XMv7ZZ.k_HZQVTM9f5LpU7P9cJlomZJqcp_rqL7B1SAP.reSUrgQs3Hz0L1kDTRmugDrEdWGabIa hU6m6lXQPk890_KUoQNJX4KzTHGZILuxezKaz73Ah_XtWvPXI7D5I7A_snkh93_afOUboyaDJxwc 1sH8mI_9k4ypYQrAPM3HXfFwGeR0X8XTJjT2QFITtjsYi.0SuDIOCiv42.OLrymR16M5_eLlXC1f xvDzgqi15YgDt8Iuc5g7HVmb_zYARtfFtL7k4wjeFa12DCfVoWenZXEl9zc.Exjd9m5fq1Jp3Zd4 pWEefaA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 29 Dec 2020 22:50:11 +0000 Received: by smtp420.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d33c7f8819c482a6c44dd5a22990d845; Tue, 29 Dec 2020 22:50: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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: Date: Tue, 29 Dec 2020 14:50:07 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <67E8786A-79E7-409A-BF4D-738F4FEB5EFF@yahoo.com> References: <20201228044840.GA28380@www.zefox.net> <20201228185622.GB28380@www.zefox.net> <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D58kr6gNvz3m0s 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.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)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.205:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.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: Tue, 29 Dec 2020 22:50:15 -0000 [clang.full built this time.] On 2020-Dec-29, at 13:24, Mark Millard wrote: > On 2020-Dec-29, at 02:15, Mark Millard wrote: >=20 >> On 2020-Dec-29, at 00:16, Mark Millard wrote: >>=20 >>> On 2020-Dec-28, at 17:02, bob prohaska wrote: >>>=20 >>>> On Mon, Dec 28, 2020 at 04:14:51PM -0800, Mark Millard wrote: >>>>> [I get the problem as well! I report a backtrace of the failure >>>>> and some more.] >>>>>=20 >>>>=20 >>>> Relieved to see it's reproducible. =20 >>> . . . >>>=20 >>> I tried reducing the size of things to be produced via building >>> the target based on the likes of using: >>>=20 >>> 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 >>> MALLOC_PRODUCTION=3D >>> WITH_MALLOC_PRODUCTION=3D >>> WITHOUT_ASSERT_DEBUG=3D >>> WITHOUT_LLVM_ASSERTIONS=3D >>> WITHOUT_DEBUG_FILES=3D >>>=20 >>> (But the host 13 was unchanged.) >>>=20 >>> It still failed, but at a different memory allocation, of a >>> different size: >>>=20 >>> r4 0x8000 32768 >>>=20 >>> (gdb) bt >>> #0 thr_kill () at thr_kill.S:4 >>> #1 0x4227d998 in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 >>> #2 0x42332284 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >>> #3 0x00da5e4c in report_bad_alloc_error () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:174 >>> #4 0x00da61c8 in out_of_memory_new_handler() () at = /usr/src/contrib/llvm-project/llvm/lib/Support/ErrorHandling.cpp:187 >>> #5 0x420f5d24 in operator new (size=3D) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:73 >>> #6 0x00e16878 in SetBufferSize () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:131 >>> #7 SetBuffered () at = /usr/src/contrib/llvm-project/llvm/lib/Support/raw_ostream.cpp:97 >>> #8 0x00e17368 in write () at = /usr/src/contrib/llvm-project/llvm/lib/Support/raw_ostream.cpp:251 >>> #9 0x00ddfe20 in operator<< () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:192 >>> #10 operator<< () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/raw_ostream.h:205 >>> #11 printSymbolizedStackTrace () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:154 >>> #12 0x00de163c in PrintStackTrace () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:575 >>> #13 0x00ddf604 in RunSignalHandlers () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:67 >>> #14 0x00de1f3c in SignalHandler () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:396 >>> #15 0x42021db4 in handle_signal (actp=3Dactp@entry=3D0x424df7b0, = sig=3D, info=3Dinfo@entry=3D0x424df7f0, ucp=3D) at /usr/src/lib/libthr/thread/thr_sig.c:303 >>> #16 0x420213f8 in thr_sighandler (sig=3D0, info=3D0x424df7f0, = _ucp=3D0x424df830) at /usr/src/lib/libthr/thread/thr_sig.c:246 >>> #17 0xffffe190 in ?? () >>> Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >>=20 >>=20 >> Updating the host 13 made no significant difference in >> behavior. >>=20 >> Using: >>=20 >> time -l /usr/bin/ld --eh-frame-hdr -Bstatic -o clang /usr/lib/crt1.o = /usr/lib/crti.o /usr/lib/crtbeginT.o = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/legac= y/usr/lib = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libz = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libexecinfo = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libelf = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/ncurses/ncursesw = -L/usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-t= ools/lib/libthr -L/usr/lib --gc-sections cc1_main.o cc1as_main.o = cc1gen_reproducer_main.o driver.o = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libclang/libclang.a = /usr/obj/rpi2_clang/arm.armv7/usr/fbsd/stable-12-src/arm.armv7/tmp/obj-too= ls/lib/clang/libllvm/libllvm.a -lz -lexecinfo -lelf -lncursesw -lpthread = -legacy -lc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/crtend.o = /usr/lib/crtn.o >>=20 >> it reported after the failure output (an example): >>=20 >> time: command terminated abnormally >> 26.59 real 9.40 user 12.48 sys >> 2052032 maximum resident set size >> 21793 average shared memory size >> 218 average unshared data size >> 127 average unshared stack size >> 703238 page reclaims >> 0 page faults >> 0 swaps >> 55 block input operations >> 3104 block output operations >> 0 messages sent >> 0 messages received >> 1 signals received >> 41126 voluntary context switches >> 447 involuntary context switches >>=20 >> where looking up getrusage reports that: >>=20 >> ru_maxrss the maximum resident set size utilized (in kilobytes). >>=20 >> which means: 44.0625 MiByte below 2 GiBytes for the resident set. >>=20 >> Adding --threads=3D1 made little difference: >>=20 >> time: command terminated abnormally >> 28.84 real 9.28 user 12.78 sys >> 2065016 maximum resident set size >> 21872 average shared memory size >> 219 average unshared data size >> 127 average unshared stack size >> 709661 page reclaims >> 0 page faults >> 0 swaps >> 48 block input operations >> 3050 block output operations >> 0 messages sent >> 0 messages received >> 1 signals received >> 36717 voluntary context switches >> 114 involuntary context switches >> Abort trap >=20 >=20 > I found another difference between how 13 is built and > stable/12 is built, so I'm trying another build. >=20 > The below shows what I've changed in stable/12 , but 13 > eliminated even having the conditional logic, always > using -O2 -pipe : >=20 > # git diff | more > diff --git a/share/mk/sys.mk b/share/mk/sys.mk > index 9099b63a61a0..53d1e30b1d56 100644 > --- a/share/mk/sys.mk > +++ b/share/mk/sys.mk > @@ -167,7 +167,7 @@ CFLAGS ?=3D -O > .else > CC ?=3D cc > .if ${MACHINE_CPUARCH} =3D=3D "arm" || ${MACHINE_CPUARCH} =3D=3D = "mips" > -CFLAGS ?=3D -O -pipe > +CFLAGS ?=3D -O2 -pipe > .else > CFLAGS ?=3D -O2 -pipe > .endif >=20 > I'll report if the use of ld to produce clang.full still > fails or not. >=20 > I've left the other things attempting to lead to less memory > use in place. >=20 With the use of -O2 instead of -O , the bootstrap clang.full linked and the later activities in building the bootstrap clang worked as well. The build has also built the bootstrap lld and is off doing things that use the bootstrap clang and lld. I've not checked if -O2 usage would be a sufficient change by itself. For one, various other aspects of my normal builds vs. yours could be different: I've not replicated your context in any detail. =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 Dec 29 23:57:09 2020 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 F26D14CED59 for ; Tue, 29 Dec 2020 23:57: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 4D5BD465kgz3q4y for ; Tue, 29 Dec 2020 23:57:08 +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 0BTNv2Ux050033 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 29 Dec 2020 15:57:02 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 0BTNv15i050032; Tue, 29 Dec 2020 15:57:01 -0800 (PST) (envelope-from fbsd) Date: Tue, 29 Dec 2020 15:57:01 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Migrating from -current to stable/12 on RPI2B (ARMv7) Message-ID: <20201229235701.GA49529@www.zefox.net> References: <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> <67E8786A-79E7-409A-BF4D-738F4FEB5EFF@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67E8786A-79E7-409A-BF4D-738F4FEB5EFF@yahoo.com> X-Rspamd-Queue-Id: 4D5BD465kgz3q4y 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.09 / 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(-0.99)[-0.991]; 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: Tue, 29 Dec 2020 23:57:10 -0000 On Tue, Dec 29, 2020 at 02:50:07PM -0800, Mark Millard wrote: > [clang.full built this time.] > > > With the use of -O2 instead of -O , the bootstrap clang.full > linked and the later activities in building the bootstrap > clang worked as well. The build has also built the bootstrap > lld and is off doing things that use the bootstrap clang > and lld. > > I've not checked if -O2 usage would be a sufficient > change by itself. For one, various other aspects of my > normal builds vs. yours could be different: I've not > replicated your context in any detail. Is adding CFLAGS=O2 to /etc/make.conf worth a try? The machine is otherwise idle at the moment. As an aside, I've tried building stable/12 sources on a Pi3B running -current. It's already gotten past the point of failure and is now building libraries. Whatever is wrong, it's not present, or at least not visible, on aarch64. Is there any hint where this bug (or feature) might reside? Thanks for your help! bob prohaska From owner-freebsd-arm@freebsd.org Wed Dec 30 01:29:07 2020 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 45A3F4D12AF for ; Wed, 30 Dec 2020 01:29:07 +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 4D5DG94hT0z3vkt for ; Wed, 30 Dec 2020 01:29:05 +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=1609291740; bh=UIveWhyYn8FDed596/D0JFQHuIPaV1MGvnCNhidn5rT=; h=Subject:From:Date:To:From:Subject; b=RA6Yhnsw/1gBLIhtTaasM1SaknDvga2cHAy0E4M+QV9iSYZzFR7Ao5nGKLmx8EtnZeeCl11fAhl1jNGEQMep+SlcpbYj+yeoFQIkm6PBjYTivGK4x2vys2Lp/Kpyw7Aonaiw85nGQDBWjAMR71JVVZU2mhNwHCYbeCARURuVrxpU8gZsDFuRdEDdU8RKiy0Rg6tgmmzHjnM0q1gE3q1O1WfXm/YrDg5u3vdPVtXI6JxVHh37JoxlH4ZBZUUMZ94+C+J4iM5BAnJsghvpBu5wSfZir8xiN7Qu6SsZuESKhMEjKLPFJc9gRDNL/BSGFPomABDxCh0T/t2HlEozGazl1Q== X-YMail-OSG: BpGc29EVM1nfL1LpcDOWT9vqK7zrcLfbyc9UHsUA4fCx90JczJ1GF.jQ4XxpFx4 PgDX4gehPH2Ci0Gmxkga7AqKhVFJk1KxGCywlINFxXHU0_dICl5YDgL1dFlQbpTmDhxtCBbM.g97 phxA8.9EpPc9pgZJQkAm5FwP4VK9MUu.HUAtT_sJxD4aE787LLBgW6RR789sqLXc3Q3TWfi74_zT LfLesp53_lcUY6I.OlCwpGsdAa83nJF6oeVrrrjKfFk7xQFZwcg7sLkpI1qD5Kf3X.4fl2BPY8lA DeTaWw.YgxIGwXFw_4G9W9r7MRkTihoW4wAu7IZP4AClD3luFj8Km5PdbTIyMElzryMKDYZrErf4 6L2ff6IS8mfUhMvgh6MoFe90ze.1b9eFkJZ1nH24HC2OQq6.HAks8LTNkyquHonloFbVXgj0fnZp mIFDTfVg8.l3W_8zDLC6JRrEq.mk0H98HXd9YYfc2gwskkqabwTdIRj3rQ6d0sR7les0e07go31V mS1tVjs6UAO4QyXMJYp_FJ_AG7wv7.SaWteByyEe8qF0EKjTqjRofDnz9mT5hpgJj4TZuyV6YtxC Q22SDem2tktGtDFLvJYrspFDp5wNtubFtzkbPwEqJ1s4Q9J_bT2mqNlZQ3ZFGqHt4IYZbEXaLjZh hYLDliLz4ZL4G_3K_FmUj.nQQ0m40bYBYy_y762Et.OS_KB5yqpaEkni..Ps.y.wBT4vCPXqjdfx Uf1RtKDK8CAZchh9s92wJi7hikW9c6mrCTAo6eYe7uoaISkyowbSktRhJ59OA7qDEPOPbRh9GFiq .w2dffXty4TfE2eMy9hibBdpfXx88A7nNVD.J6_8fhsjCX2stBHyQbAv5.s4C0Ubwo2pz5laXIKL wnDUiawnc51J81J20UXkJbwFMDiKeRGA9hMIHCxZ77JfrA2kvu.jssccUsQrAuQGe2ZYjmLX7eCl LfxDDXRejV3tfIV5tp_Lx7m03SJSsWuSR9.qmh3xMHbxCudwi.eBXtQVhF0BkRa4E4O8R8S5uWwJ HuTTekkN.wGfHuEUETQXrlHaZ3ZGpcGSQ_uECTD2oyUJfAwmt8iadrd.1.0eFG6L32SJ8oGRQnhz NzXO6oqF14.YbCrKaBLoP37Sfric2uXFyfx8KKYCmxR1N9CceMKscIuhI82HTOOAao00oixlFEHB 4arNsmnz6e.biU3yGHtpnXV9E2PlTnwFJ9zdRiUBXr0YW7XoAu25d354cnFMF1GkyRb0uzbIQepd DfeDXxSK_BxQ5aUcRops4XCqdD4ZaF.pYLRr1iEMO8_3g18JW0fjYuuLqTBACRBVTttw0q7bHs4n V1zMTmXacZp7pC65M9CGYKBYfSpKGA.8x48KEzpzr3Ka3JWF2t_QjalonpRG2z4Ha8Ykanft1OUc g.lhYNbRWoLdJZIpZgypCPKr55hVD50ThrYSf60zZHvYFqLTPhmfjnpbiPCDUS.VjcoUCoBGCKAq mdmmLRy3Jm5ogELyu3afu4E5i5dlXrwVXN2BBtppiiWsmsbx3D0.wJNvTohgLaCaYZXdT4CW0XMA xKhmQDjYQOpOF8zIhkQcfTq02FA0M5.f_Pq.R7LrYRggf7fvzfHnr0UHBqEHIUhnHOmgz8lCd6BP GXJoY4uNzuCmw9wDOFpy0kvWgHTl8artCxMon0A8ZLnkH23dBeR_bqT93yklSfbHBpe8aaHfs2bf DjzkQ3mZ86ZcNk79OpjkgQjVHveVMZN2u.mU4AkzXIcqv1h9QK1AVAOhs2ZNC9rXVrqFE2lBZt70 EfWaMj_l0DG7cP1V6IommYPDoaquGW_YTiwgLiuluYhfEsL_ovsoc75vk9KTlVVUl5C5onbfuP8E JEqXjsdC2Vb4Ao7WMLvwrnDW9Y2mTTwk.rK9oN2W.GlNm8cBQbAngJhm6IvLEz7jlu26TfRcN96z z9yn5_baXpfIM0g0DY.b_pLs2LmSSu_AeBdbhi33mgpUxEtLJsXY8o7uR.uOPLkzEVaJoNzW9cF0 OlUxQ8.d8MvlyE2uQhj3bK7yMRYyak3RQLi1sw4zROJ2TR6CY2MxE3QGtcDoQjaLg7Gm6er6kgsO V0TYmjCY2.VDn9UrXysaMVP_sagpsaWHWBcR9mQm9_jfi8RHVxeodJBcsyIOLL5z54y1apBOojfB XkMJRYeuKSWa5VhP8aUAjdSRyWs2GxjS4uSiCtsu3q4L.q2UKsXLaSbfDie5.rxWta8qagixFN0p 8nG.blLq1jGaaMnbSnXUjhGDYsrkIhMVr9oVfB7fr3JoGzVrHCnN71Pcht_k8ahRErQGvfRNArGP 8iaoFpemH_LPOkV6Y_ZOcx0iV7KtdaqSLQ1miIQvKL9TrB9ZABa8jg.RUG0.OPKz7CPMeS.eMzcb RrdZ3llvDOL8KVxN1Y25CUYMRMmXqz6MtB4cF.WiBpX3qJZA6JALHSkWHflXbEtW0lWuvxUn.XFi TIEp3I1P6_bN6KgYm3CyEf0dN2A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 30 Dec 2020 01:29:00 +0000 Received: by smtp402.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4ce98856f154ea40ef9c552c3fa6f1a1; Wed, 30 Dec 2020 01:28:57 +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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <20201229235701.GA49529@www.zefox.net> Date: Tue, 29 Dec 2020 17:28:55 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2C1E2F87-2FC3-481C-A508-C76B2D7CFF7F@yahoo.com> <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> <67E8786A-79E7-409A-BF4D-738F4FEB5EFF@yahoo.com> <20201229235701.GA49529@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D5DG94hT0z3vkt 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.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.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: Wed, 30 Dec 2020 01:29:07 -0000 On 2020-Dec-29, at 15:57, bob prohaska wrote: > On Tue, Dec 29, 2020 at 02:50:07PM -0800, Mark Millard wrote: >> [clang.full built this time.] >>=20 >>=20 >> With the use of -O2 instead of -O , the bootstrap clang.full >> linked and the later activities in building the bootstrap >> clang worked as well. The build has also built the bootstrap >> lld and is off doing things that use the bootstrap clang >> and lld. >>=20 >> I've not checked if -O2 usage would be a sufficient >> change by itself. For one, various other aspects of my >> normal builds vs. yours could be different: I've not >> replicated your context in any detail. >=20 > Is adding CFLAGS=3DO2 to /etc/make.conf worth a try? The machine > is otherwise idle at the moment.=20 I'll deal with controlling -O2 use later in this note. It is a bit messy in my experience so it is not near a one word response. > As an aside, I've tried building stable/12 sources on a Pi3B running = -current. > It's already gotten past the point of failure and is now building = libraries. > Whatever is wrong, it's not present, or at least not visible, on = aarch64.=20 > Is there any hint where this bug (or feature) might reside? If you run armv7 FreeBSD on the RPi3B it will behave like the RPi2 v1.1 = does: it will fail. You must be running the aarch64 FreeBSD on the RPi3B for = what you state above to be true. The RPi2 v1.1 can not run the aarch64 = FreeBSD. So: it is not a bug. armv7 user processes are each limited to (virtual) = 2 GiBytes (or somewhat less) user-process-address-space (32 bit addressing, with a = bit reserved). aarch64 user processes are not each limited to a (virtual) 2 = GiByte user-process-address-space: the user-process-address-space bound is much = larger so the effective bound is based on other things. aarch64 still usually = ends up with a larger effective user-process size limit than 2 GiByte (depending = on RAM size and swap/paging space configuration, for example). What -O2 is doing is inlining functions and the like, cutting the amount of linking of functions and the like at ld time: -O2 make the linking less memory-size-needed intensive. Back to building vs. assigning CFLAGS . . . Directly assigning CFLAGS (CFLAGS=3D or CFLAGS+=3D style) can be = problematical, with that definition possibly overriding internal definitions by = preventing internal CFLAGS?=3D usage from picking up material or other such in = contexts=20 one is not trying to control (nested contexts). I have run into such = issues historically. Here we are trying to control something normally supplied internal to = the build infrastructure, only in places where that stable/12 = infrsuctcture's normal CFLAGS?=3D -O -pipe would have done the assignment. We do not want to be adjusting other contexts that do things with CFLAGS ( including, possibly, other uses of -O in nested contexts). We probably also do not want to analyze the whole build infrastructure looking for places to worry about inappropriate overriding and figuring out what to do for them. Such also applies to using, say, CFLAGS.clang+=3D that would add separate text to the command lines without disabling the CFLAGS?=3D = usage (for example). Then things get into order of conflicting options and which "wins" and if that is always an appropriate result. So the only simple technique that I know of is to change the actual file ( share/mk/sys.mk ) that has the above line. That limits itself to the correct context directly. Only the share/mk/sys.mk copy in the file = system needs to be changed: no need to have, say, a git branch of your own = (unless you want such). I've run into this before and have used my own share/mk/sys.mk variant as needed. I actually use CFLAGS.clang+=3D and the like for something = but would not use it for this -O2 vs. -O issue. If you still try your own CFLAGS assignment, include the -pipe as well: CFLAGS=3D -O2 -pipe Otherwise the -pipe will end up missing. =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 Dec 30 03:54:50 2020 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 D89EC4D3A56 for ; Wed, 30 Dec 2020 03:54: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 4D5HVK5mT4z4YJQ for ; Wed, 30 Dec 2020 03:54:49 +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 0BU3smU0050733 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 29 Dec 2020 19:54:48 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 0BU3smxa050732; Tue, 29 Dec 2020 19:54:48 -0800 (PST) (envelope-from fbsd) Date: Tue, 29 Dec 2020 19:54:47 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Migrating from -current to stable/12 on RPI2B (ARMv7) Message-ID: <20201230035447.GA50440@www.zefox.net> References: <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> <67E8786A-79E7-409A-BF4D-738F4FEB5EFF@yahoo.com> <20201229235701.GA49529@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4D5HVK5mT4z4YJQ 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.08 / 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.99)[-0.989]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; 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: Wed, 30 Dec 2020 03:54:50 -0000 On Tue, Dec 29, 2020 at 05:28:55PM -0800, Mark Millard wrote: > > > On 2020-Dec-29, at 15:57, bob prohaska wrote: > > > On Tue, Dec 29, 2020 at 02:50:07PM -0800, Mark Millard wrote: > >> [clang.full built this time.] > >> > >> > >> With the use of -O2 instead of -O , the bootstrap clang.full > >> linked and the later activities in building the bootstrap > >> clang worked as well. The build has also built the bootstrap > >> lld and is off doing things that use the bootstrap clang > >> and lld. > >> > >> I've not checked if -O2 usage would be a sufficient > >> change by itself. For one, various other aspects of my > >> normal builds vs. yours could be different: I've not > >> replicated your context in any detail. > > > > Is adding CFLAGS=O2 to /etc/make.conf worth a try? The machine > > is otherwise idle at the moment. > > I'll deal with controlling -O2 use later in this note. It is a bit > messy in my experience so it is not near a one word response. > > > As an aside, I've tried building stable/12 sources on a Pi3B running -current. > > It's already gotten past the point of failure and is now building libraries. > > Whatever is wrong, it's not present, or at least not visible, on aarch64. > > Is there any hint where this bug (or feature) might reside? > > If you run armv7 FreeBSD on the RPi3B it will behave like the RPi2 v1.1 does: > it will fail. You must be running the aarch64 FreeBSD on the RPi3B for what > you state above to be true. The RPi2 v1.1 can not run the aarch64 FreeBSD. > Yes, the success case ran aarch64 on the Pi3B. > So: it is not a bug. armv7 user processes are each limited to (virtual) 2 GiBytes > (or somewhat less) user-process-address-space (32 bit addressing, with a bit > reserved). Doesn't that make it a bug specific to armv7? Perhaps not global, but a bug so far as users of ld would see it. > aarch64 user processes are not each limited to a (virtual) 2 GiByte > user-process-address-space: the user-process-address-space bound is much larger > so the effective bound is based on other things. aarch64 still usually ends up > with a larger effective user-process size limit than 2 GiByte (depending on > RAM size and swap/paging space configuration, for example). > > What -O2 is doing is inlining functions and the like, cutting the amount > of linking of functions and the like at ld time: -O2 make the linking > less memory-size-needed intensive. > > > > Back to building vs. assigning CFLAGS . . . > > Directly assigning CFLAGS (CFLAGS= or CFLAGS+= style) can be problematical, > with that definition possibly overriding internal definitions by preventing > internal CFLAGS?= usage from picking up material or other such in contexts > one is not trying to control (nested contexts). I have run into such issues > historically. > > Here we are trying to control something normally supplied internal to the > build infrastructure, only in places where that stable/12 infrsuctcture's > normal > > CFLAGS?= -O -pipe > > would have done the assignment. We do not want to be adjusting other > contexts that do things with CFLAGS ( including, possibly, other uses > of -O in nested contexts). > > We probably also do not want to analyze the whole build infrastructure > looking for places to worry about inappropriate overriding and figuring > out what to do for them. > > Such also applies to using, say, CFLAGS.clang+= that would add > separate text to the command lines without disabling the CFLAGS?= usage > (for example). Then things get into order of conflicting options and > which "wins" and if that is always an appropriate result. > > So the only simple technique that I know of is to change the actual file > ( share/mk/sys.mk ) that has the above line. That limits itself to the > correct context directly. Only the share/mk/sys.mk copy in the file system > needs to be changed: no need to have, say, a git branch of your own (unless > you want such). Looking at /usr/freebsd-src/share/mk/sys.mk I don't find a CFLAGS.clang line. There is a snippet containing .if ${MACHINE_CPUARCH} == "arm" || ${MACHINE_CPUARCH} == "mips" CFLAGS ?= -O -pipe .else CFLAGS ?= -O2 -pipe .endif Indeed, I don't see anything that distinguishes armv7 from arm64. Am I looking at the wrong file? /usr/freebsd-src is the stable/12 build directory, cloned by git. Or, is that the problem, that armv7 and arm64 are treated the same way? > > I've run into this before and have used my own share/mk/sys.mk variant > as needed. I actually use CFLAGS.clang+= and the like for something but > would not use it for this -O2 vs. -O issue. > > If you still try your own CFLAGS assignment, include the -pipe as well: > > CFLAGS= -O2 -pipe > > Otherwise the -pipe will end up missing. > Are you referring to /etc/make.conf? That seems preferable to tampering with makefiles. With my thanks (and apologies for dumb questions)! bob prohaska From owner-freebsd-arm@freebsd.org Wed Dec 30 06:49:16 2020 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 A542C4B8BCA for ; Wed, 30 Dec 2020 06:49:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.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 4D5MMb4mwyz4jJt for ; Wed, 30 Dec 2020 06:49: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=1609310953; bh=B26VI6fDMj75YoHdJtq55CNcQJQuM6XkHJrMLqj7SiB=; h=Subject:From:Date:To:From:Subject; b=gbXl/hvfPwveNTKB4DMPTBMSdzr/QclG098E8UizgVUAmN8/2MTOx50OXquCJGDHL42CkTpB2OS+NHKR6EkozvCMP6tRQmm+jRT+x5a5vLhw9CCjTMM+JaffoV1Hxj4OUa2Vj6L5eeW52F2t7MEe7fTP8GxM/odgNfjPLAjGh8bjkYXCsAz25qIt7hlhxiY5RQLICJxM9ZNFdZJHZKaHqLVSBn4r1bpOwpOnFhY7PxzAN6BUKz1cQjYm269KORW2hUtNf/lwooqXy9ka7F1iKDxQHv46aV2EK+aRBgD35h58+fykQKwUQ1gDmdI4WzlLUkf9bXt1Ix2MpGMA1Y2sVA== X-YMail-OSG: MYdWSqIVM1k.BanhrEPFKyxR.CBLSn0uCQs7bc5UORtpmmocnV16RLPt_JRXACH QmyB9SPCWCQGACiHWIDWFPjONOGnfIGtUs8EGCyxRAV.KIb2O.b59nWuO26bvNB9pa9v4iFYBvdv cm7uKK_RPOjwwcp_K_DQ5dlizvx1rAYC4Ihruj0hg28l7mfDrmCcZUT9YzmhmkPAPFDtWWhxxfq2 4syHWudO3WFlrXgBMAfBgLsL4pyppti0f6S6xsOEbxoBniTr6jLLo8mCeCG4GxSrlqhCefYC2DOQ 2gzaE68APO.MBKYlOMtBJ4vmSfss8cNy1XiBfiXiMVvIf2jrp4MaNTudGpp9ZhxH4RLjkxpv52mL NH4lws2187bVGFe.273Dmmp7xikuA7yujNuhWGE1tA9K5eDbII64ildc8E87iZCNWj8sFm0YgT3L cUufcWqBLFov8zM_PGykuRDQZOV164_P4EE2nFDZyf6.K1uHJljGWO5Pmh13i9hlwmeK6kHX6S1s S4e3JrNTt.rw5LGVGXvQCSyYxZJqjGz8QA8z6KA22VrFHv__anRzbL8ZfLSLg7i_ondmrh.5KtkB Ug1xmuG9Te9av8N4ZP0RTeVVJLxwoVbE7LQuhs.xrspFk15ck2QWyYJz92BdjUIhgi4X4.W1hvB7 V8Gn28KDp8D7JpVuAK0bQQYKH7GO95KQotfddM7fmTtAshv9NK9aZWi0qTzXUlFxNh7KAqG43Yzu 0RJjXkpHhQc8xCq_kP473xfTSKImgyFZYNdv4w54Abpfd6aQQkz2p581inxlrLSjGeyQjEmZO43q hM66uvVeUrHzCKRPO0SO61CyKHqTrzjEpBVBnrM6gfTx6sylZiOaZj56cwV8EDBrnH_CRHAzPXtK A2NjYtl2WogGZ1ipEcWRD8sIav2IouQGibyEhx7guUUH3wAaB8eHQzyEHkCo6JYJvUwSBinfwLDz Fdob93DguRYqYkFs0y3DOoj2_tSXCTGqdrCZ_eI604emMSdEZSHXmuv8CjK_6SqSLUhF4xIL0eVA g82KtPr9G8UzA9JixYFdLWMtwRfVfB2BypuIgKSUin2ypkjhbti3TcSPD0ZKAXUtWnC2oynn2GoQ mokkriiJhve1.H4WHaexpxuPAuEPKsnJz0EIElJ4tBsVAGxtlp3B6oZiXAg3CvjlpXH9pKJ0k6HZ T7FpP6wqZ7hP0A.OholOLOW1Sd.fhgW3aHt33ws3.oF4WMddUxo6QnjXFLLeoh1VOShVPJVAk199 2cq0w6hC9xdgJqHaUIsyoyrP27IKNbYbEVdHLzI5LFLRzbw2Fg6graS.5flgTz1cB.tjbfo162ft PubjqXI7zSYfFE9hW2P.HcHy6RDRWvDsiRK4iey0Ru7FYIonu00JRqlgShUV.kLatE9L.vq.M7fy P69M.ATyLK_qkVf5ka7nTnBOUbAT80h7ipdfq4ZlE9C66muRF4bHZSTTHC8gI1qJ2I1IGNPkZNaE Jrkyf20HdDUF_P3CaQ8R2Ts2jPlYEZFeJ_4o8aNVQEojauLabORkwTrK6..af84od9SUWs6lEXVa U_KkVChvrFZGcwl4GtNysWtRwvoYncLEVDrBmHBa7oxADnQUcV43NOriLG_i3MOrSQUdaymtps85 MSnYLhOzXKUFKpObIiofIK7NphxgCIdfzVyzBJ4vQMmnuSo5YMky63Er3piJAzs7n2671hPzdv91 S49EtsxaNy_u39k.BQvvoQjaoYFSj4VTtqdNjqqAVtCUyMe5OVMO6ZjARNaows3zK2j6VgrvuTqM bW1W1wHWM.UBT3ow7hk74aaIRWhyd1YNCmC3K48vR6.5O8x.hsL8knaAf3InXo6i81ULLqmGhSQa FYTXJKkiqpuijyfRboAEbReqJ0VpHq.J3xkG9aQMxQleIoRboMwt7BP7pAV2rtZUNqRDFvUlusUb Y6BMAAGtYuFTefadwpEF7RRXYwk8JT3R.AWRhHxhm5kX0HBPTmvBJWslQ0AVtdoRpTM6tKYJBibK JHDcFpLHeqTwXl2HF736VVALWTrUOhOkgsoTM99uDiaiwzRAEoS8tqCKHQmvQ1wRKhdumWqZ021X 7kh16EKSZUM0CObJFpkf.XtgnA6_q.b3d6fM6PLYU4.L5blS5S2ypTxXnHGHTtb9foHefmXqSexU E3gJ341h.rfY.BXoaATTBqlYFwhu2TBCBrWXX2H7_kUcNizvG.mDO_1Tj8QxS7hDvkua.I7.0KDn 1f1WqHsCFZt5_rKpmvLq5fz8nNC7J0uByGmiSQhy5znC1jC0IPfyhA2LZZbXobd7VcnSUPDka.an fAN8RHnCSAWn2IdQMFQbncRNBnF1vf_OTDj2gfhsuOFSu.FWX9j4EH42lL8AnWwsHayKihYI2wD. UUhm24Ts7PNcxqrx4Hop15m5_qzDzLm_yp384O1BzgFzMQ0OM5v2skljzy_k0VbCV8NFQiaOkawO 0SzOrZQ2Ng.o3vzpy3sMRC5fSXnzpfIrjZLetA8O4_2fBqDYYt8H_Wkp4zZGG9135xHQ0IXMiUxw TA20- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 30 Dec 2020 06:49:13 +0000 Received: by smtp420.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3da63174b7172dd787c94ca1f3839876; Wed, 30 Dec 2020 06:49:11 +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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <20201230035447.GA50440@www.zefox.net> Date: Tue, 29 Dec 2020 22:49:09 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <619A02CC-0EBA-4B50-A3BB-C326996AE706@yahoo.com> <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> <67E8786A-79E7-409A-BF4D-738F4FEB5EFF@yahoo.com> <20201229235701.GA49529@www.zefox.net> <20201230035447.GA50440@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D5MMb4mwyz4jJt 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.64.30: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.64.30:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.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: Wed, 30 Dec 2020 06:49:16 -0000 On 2020-Dec-29, at 19:54, bob prohaska wrote: > On Tue, Dec 29, 2020 at 05:28:55PM -0800, Mark Millard wrote: >>=20 >>=20 >> On 2020-Dec-29, at 15:57, bob prohaska wrote: >>=20 >>> On Tue, Dec 29, 2020 at 02:50:07PM -0800, Mark Millard wrote: >>>> [clang.full built this time.] >>>>=20 >>>>=20 >>>> With the use of -O2 instead of -O , the bootstrap clang.full >>>> linked and the later activities in building the bootstrap >>>> clang worked as well. The build has also built the bootstrap >>>> lld and is off doing things that use the bootstrap clang >>>> and lld. >>>>=20 >>>> I've not checked if -O2 usage would be a sufficient >>>> change by itself. For one, various other aspects of my >>>> normal builds vs. yours could be different: I've not >>>> replicated your context in any detail. >>>=20 >>> Is adding CFLAGS=3DO2 to /etc/make.conf worth a try? The machine >>> is otherwise idle at the moment.=20 >>=20 >> I'll deal with controlling -O2 use later in this note. It is a bit >> messy in my experience so it is not near a one word response. For more background I'll quote from 2 clang documents, one each for 10 vs. 11 of clang: = https://releases.llvm.org/10.0.0/tools/clang/docs/CommandGuide/clang.html = : -O Equivalent to -O2. = https://releases.llvm.org/11.0.0/tools/clang/docs/CommandGuide/clang.html = : -O Equivalent to -O1. So -O in stable/12 (clang 10) and in FreeBSD 13 (clang 11) are not equivalent. FreeBSD 13 does not use -O any more: it uses -O2 . Using -O2 notation makes the clang compilers in both FreeBSD's behave similarly. -O does not. I've no clue why stable/12 has not had some approximate MFC of the clang -O2 notation. You might be able to get some committer to take that point of view and update stable/12 . I've been writing for as things are presently. That will continue some below. As things are, you are out of the bounds that FreeBSD currently supports when you try to build stable/12 on an armv7 FreeBSD 13 (or armv6 FreeBSD 13) with the built-in toolchain (counting stable/12's Makefile*'s). (The same likely applies to 32-bit powerpc.) >>> As an aside, I've tried building stable/12 sources on a Pi3B running = -current. >>> It's already gotten past the point of failure and is now building = libraries. >>> Whatever is wrong, it's not present, or at least not visible, on = aarch64.=20 >>> Is there any hint where this bug (or feature) might reside? >>=20 >> If you run armv7 FreeBSD on the RPi3B it will behave like the RPi2 = v1.1 does: >> it will fail. You must be running the aarch64 FreeBSD on the RPi3B = for what >> you state above to be true. The RPi2 v1.1 can not run the aarch64 = FreeBSD. >>=20 > Yes, the success case ran aarch64 on the Pi3B. >=20 >> So: it is not a bug. armv7 user processes are each limited to = (virtual) 2 GiBytes >> (or somewhat less) user-process-address-space (32 bit addressing, = with a bit >> reserved).=20 >=20 > Doesn't that make it a bug specific to armv7? Perhaps not global, but = a bug > so far as users of ld would see it.=20 That the armv7 (/armv6) always has a "small" address space is a hardware issue (instruction set architecture), not software. That -O1 (and clang 11's -O) requires more than 2 GiByte per-process spaces to build clang.full is the consequence of (mostly) LLVM choices. FreeBSD chooses to be LLVM based and FreeBSD 13 chooses to be LLVM 11 based (until LLVM 12?). The closet things to a "bug" here is stable/12's use of -O . But FreeBSD does not define its correctness relative to using armv7, armv6, or 32-bit powerpc as you are trying to using it. (That does not mean an MFC of -O2 use to stable/12 is out of the question. It is just not on a main line of development for FreeBSD.) I'll note that cross-building from machines with a larger maximum per-process-space size still allows targeting armv7 and the like with -O in use. You could do a cross-build on the RPi3B from an arm64 FreeBSD context. Such is one of the reasons the LLVM folks do not=20 worry as much about builds that can not finish in a 2 GiByte maxmimum per-process context. >> aarch64 user processes are not each limited to a (virtual) 2 GiByte >> user-process-address-space: the user-process-address-space bound is = much larger >> so the effective bound is based on other things. aarch64 still = usually ends up >> with a larger effective user-process size limit than 2 GiByte = (depending on >> RAM size and swap/paging space configuration, for example). >>=20 >> What -O2 is doing is inlining functions and the like, cutting the = amount >> of linking of functions and the like at ld time: -O2 make the linking >> less memory-size-needed intensive. >>=20 >>=20 >>=20 >> Back to building vs. assigning CFLAGS . . . >>=20 >> Directly assigning CFLAGS (CFLAGS=3D or CFLAGS+=3D style) can be = problematical, >> with that definition possibly overriding internal definitions by = preventing >> internal CFLAGS?=3D usage from picking up material or other such in = contexts=20 >> one is not trying to control (nested contexts). I have run into such = issues >> historically. >>=20 >> Here we are trying to control something normally supplied internal to = the >> build infrastructure, only in places where that stable/12 = infrsuctcture's >> normal >>=20 >> CFLAGS?=3D -O -pipe >>=20 >> would have done the assignment. We do not want to be adjusting other >> contexts that do things with CFLAGS ( including, possibly, other uses >> of -O in nested contexts). >>=20 >> We probably also do not want to analyze the whole build = infrastructure >> looking for places to worry about inappropriate overriding and = figuring >> out what to do for them. >>=20 >> Such also applies to using, say, CFLAGS.clang+=3D that would add >> separate text to the command lines without disabling the CFLAGS?=3D = usage >> (for example). Then things get into order of conflicting options and >> which "wins" and if that is always an appropriate result. >>=20 >> So the only simple technique that I know of is to change the actual = file >> ( share/mk/sys.mk ) that has the above line. That limits itself to = the >> correct context directly. Only the share/mk/sys.mk copy in the file = system >> needs to be changed: no need to have, say, a git branch of your own = (unless >> you want such). >=20 > Looking at /usr/freebsd-src/share/mk/sys.mk I don't find a = CFLAGS.clang line. I was not trying to imply that you would find such in FreeBSD files. = (There is code that enables such notation to be used.) I have such .clang notation in use in my own files, not in modified = FreeBSD files. You likely do not want the self-support tradeoffs involved, = including the build environment knowledge gathering involved for figuring out when the notation will work sufficiently for your purposes. > There is a snippet containing > .if ${MACHINE_CPUARCH} =3D=3D "arm" || ${MACHINE_CPUARCH} =3D=3D = "mips" > CFLAGS ?=3D -O -pipe > .else > CFLAGS ?=3D -O2 -pipe > .endif >=20 > Indeed, I don't see anything that distinguishes armv7 from arm64.=20 True. armv7/armv6/arm64 have been using -O in stable/12 and now use -O2 in 13. (But -O means very different things in stable/12 vs. in 13, because of the different clang versions involved.) 13 uses -O2 for everything now. The reference to the armv6/armv7/arm64 change is: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D3502= 10 which shows in the sys.mk log as: Revision 350210 - (view) (download) (annotate) - [select for diffs]=20 Modified Mon Jul 22 10:17:59 2019 UTC (17 months, 1 week ago) by manu=20 File length: 8664 byte(s)=20 Diff to previous 335452 arm: Use -O2 instead of -O as optimization flag When using Clang -O is equivalent to -O2, change it -O2 to make it consistent with other platforms. Reference:=20 = https://clang.llvm.org/docs/ClangCommandLineReference.html#optimization-le= vel Submitted by: Daniel Engberg (daniel.engberg.lists@pyret.net) Reviewed by: emaste Differential Revision:=09 https://reviews.freebsd.org/D21021 Note the implication of the description: at the time -O and -O2 were equivalent for armv7/armv6/arm64. That is no longer true of clang 11 and FreeBSD 13. Later ( -r366664 ) mips was also changed. That is when having = conditional logic was removed. By this later time frame clang 11 had changed -O to mean -O1 instead of -O2. So to get the historical standard output, -O2 had to be used instead when clang 11 was doing the compiling. > Am I looking at the wrong file? That is the correct file. armv7 was not the only type of arm target changed: armv7 is just an example for the change. The earlier code that you quote is the same text from the same file that I showed in a git diff that showed the change I made to do my test. It was a one character addition for how I did it for my test. As of mips also changing, 13 had deleted the first 3 lines that you show and the .endif line as well. (Such is equivalent to what I did by instead adding one character to what stable/12 had there.) What 13 did should be fine for your use if you want to do such: equivalent. > /usr/freebsd-src is the stable/12 > build directory, cloned by git. Or, is that the problem, that armv7=20 > and arm64 are treated the same way?=20 arm64 builds clang.full either way in FreeBSD 13 but -O2 will produce faster LLVM toolchain programs. armv7 does not build clang.full when -O is in use on FreeBSD 13 and -O2 can work. When FreeBSD 13 builds stable/12 it uses stable/12's option to build clang.full , and that option is still -O as things are. Thus FreeBSD 13 does not support the operation as-is. >>=20 >> I've run into this before and have used my own share/mk/sys.mk = variant >> as needed. I actually use CFLAGS.clang+=3D and the like for something = but >> would not use it for this -O2 vs. -O issue. >>=20 >> If you still try your own CFLAGS assignment, include the -pipe as = well: >>=20 >> CFLAGS=3D -O2 -pipe >>=20 >> Otherwise the -pipe will end up missing. >>=20 >=20 > Are you referring to /etc/make.conf? WARNING: /etc/make.conf and /etc/src.conf are not limited to buildworld buildkernel use. For example, port builds can also use the likes of /etc/make.conf . Thus one ends up managing the content of those files as one switches what type of thing is being built. (The port build technique matters here, I'll not get into the details.) Yet, even for just buildworld buildkernel contexts: As an illustration of why such is bad: if CFLAGS already has a value the use of CFLAGS=3D would destroy the value if executed. (Is /etc/make.conf only included once for over the whole buildworld build kernel? At exactly which stage(s) relative to share/mk/sys.mk ? Do you want to analyze such things?) By contrast: CFLAGS?=3D -O2 -pipe avoids that issue but then what you get is dependent on which CFLAGS?=3D happens first in the detailed ordering of operations whenever /etc/make.conf is involved/executed. > That seems preferable to tampering > with makefiles.=20 The point of my notes was that, in this type of context, that is not necessarily true. I have reported that I have had example problems controlling -O2 use (or similar) and what my investigation indicated to me as what was simpler that would work --and that is what I use when I do not want to do what FreeBSD does for -O2 type options. (I do not normally build stable/12 or other such and so the issue does not normally show up for me in modern times.) Hopefully the notes will help if you try things and have problems. But the simplest thing at this point is to add the one character to stable/12's share/mk/sys.mk ( until/unless you get someone to MFC -O2 use into stable/12 ). > With my thanks (and apologies for dumb questions)! >=20 What dumb questions? Each point has at some point in the past been an investigation for me. None of it was magically obvious. You are welcome. =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 Dec 30 18:30:57 2020 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 25E3D4CB473 for ; Wed, 30 Dec 2020 18:30:57 +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 4D5fxC4WK3z4VfB for ; Wed, 30 Dec 2020 18:30:55 +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 0BUIUrHt056986 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 30 Dec 2020 10:30:53 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 0BUIUrJp056985; Wed, 30 Dec 2020 10:30:53 -0800 (PST) (envelope-from fbsd) Date: Wed, 30 Dec 2020 10:30:52 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Migrating from -current to stable/12 on RPI2B (ARMv7) Message-ID: <20201230183052.GA56823@www.zefox.net> References: <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> <67E8786A-79E7-409A-BF4D-738F4FEB5EFF@yahoo.com> <20201229235701.GA49529@www.zefox.net> <20201230035447.GA50440@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4D5fxC4WK3z4VfB 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.21 / 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.11)[-0.110]; 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: Wed, 30 Dec 2020 18:30:57 -0000 On Tue, Dec 29, 2020 at 10:49:09PM -0800, Mark Millard wrote: > > > On 2020-Dec-29, at 19:54, bob prohaska wrote: > > > On Tue, Dec 29, 2020 at 05:28:55PM -0800, Mark Millard wrote: > >> > >> > >> On 2020-Dec-29, at 15:57, bob prohaska wrote: > >> > >>> On Tue, Dec 29, 2020 at 02:50:07PM -0800, Mark Millard wrote: > >>>> [clang.full built this time.] > >>>> > >>>> > >>>> With the use of -O2 instead of -O , the bootstrap clang.full > >>>> linked and the later activities in building the bootstrap > >>>> clang worked as well. The build has also built the bootstrap > >>>> lld and is off doing things that use the bootstrap clang > >>>> and lld. > >>>> > >>>> I've not checked if -O2 usage would be a sufficient > >>>> change by itself. For one, various other aspects of my > >>>> normal builds vs. yours could be different: I've not > >>>> replicated your context in any detail. > >>> > >>> Is adding CFLAGS=O2 to /etc/make.conf worth a try? The machine > >>> is otherwise idle at the moment. > >> > >> I'll deal with controlling -O2 use later in this note. It is a bit > >> messy in my experience so it is not near a one word response. > > For more background I'll quote from 2 clang documents, one each for > 10 vs. 11 of clang: > > https://releases.llvm.org/10.0.0/tools/clang/docs/CommandGuide/clang.html : > > -O Equivalent to -O2. > > https://releases.llvm.org/11.0.0/tools/clang/docs/CommandGuide/clang.html : > > -O Equivalent to -O1. > > So -O in stable/12 (clang 10) and in FreeBSD 13 (clang 11) are not > equivalent. FreeBSD 13 does not use -O any more: it uses -O2 . > > Using -O2 notation makes the clang compilers in both FreeBSD's behave > similarly. -O does not. > > I've no clue why stable/12 has not had some approximate MFC of the clang > -O2 notation. You might be able to get some committer to take that point > of view and update stable/12 . > > I've been writing for as things are presently. That will continue some > below. > > As things are, you are out of the bounds that FreeBSD currently supports > when you try to build stable/12 on an armv7 FreeBSD 13 (or armv6 FreeBSD > 13) with the built-in toolchain (counting stable/12's Makefile*'s). (The > same likely applies to 32-bit powerpc.) > It's worse than that: I'm trying to turn back time. I wanted to test the stable-12 upgrade path for armv7 and used the 13-current box because it was handy and expected backward compatibility. Makes no sense in the context of an OS. It makes more sense to wait for stable/13 to emerge and test that, given that 13-current seems to work with armv7. The handbook warns against crossing major versions, doing it in reverse compounds the trouble, since developers have no reason to expect anybody in their right mind _wanting_ to do it. > >>> As an aside, I've tried building stable/12 sources on a Pi3B running -current. > >>> It's already gotten past the point of failure and is now building libraries. > >>> Whatever is wrong, it's not present, or at least not visible, on aarch64. > >>> Is there any hint where this bug (or feature) might reside? > >> > >> If you run armv7 FreeBSD on the RPi3B it will behave like the RPi2 v1.1 does: > >> it will fail. You must be running the aarch64 FreeBSD on the RPi3B for what > >> you state above to be true. The RPi2 v1.1 can not run the aarch64 FreeBSD. > >> > > Yes, the success case ran aarch64 on the Pi3B. > > > >> So: it is not a bug. armv7 user processes are each limited to (virtual) 2 GiBytes > >> (or somewhat less) user-process-address-space (32 bit addressing, with a bit > >> reserved). > > > > Doesn't that make it a bug specific to armv7? Perhaps not global, but a bug > > so far as users of ld would see it. > > That the armv7 (/armv6) always has a "small" address space is a hardware > issue (instruction set architecture), not software. That -O1 (and clang > 11's -O) requires more than 2 GiByte per-process spaces to build > clang.full is the consequence of (mostly) LLVM choices. FreeBSD chooses > to be LLVM based and FreeBSD 13 chooses to be LLVM 11 based (until LLVM > 12?). > Given the continued "expansion" of LLVM, it seems likely that before long it will become incompatible with armv7, despite the use of optimization. Does this seem correct? > The closet things to a "bug" here is stable/12's use of -O . But FreeBSD > does not define its correctness relative to using armv7, armv6, or > 32-bit powerpc as you are trying to using it. (That does not mean an MFC > of -O2 use to stable/12 is out of the question. It is just not on a main > line of development for FreeBSD.) > > I'll note that cross-building from machines with a larger maximum > per-process-space size still allows targeting armv7 and the like with > -O in use. You could do a cross-build on the RPi3B from an arm64 > FreeBSD context. Such is one of the reasons the LLVM folks do not > worry as much about builds that can not finish in a 2 GiByte > maxmimum per-process context. > > >> aarch64 user processes are not each limited to a (virtual) 2 GiByte > >> user-process-address-space: the user-process-address-space bound is much larger > >> so the effective bound is based on other things. aarch64 still usually ends up > >> with a larger effective user-process size limit than 2 GiByte (depending on > >> RAM size and swap/paging space configuration, for example). > >> > >> What -O2 is doing is inlining functions and the like, cutting the amount > >> of linking of functions and the like at ld time: -O2 make the linking > >> less memory-size-needed intensive. > >> > >> > >> > >> Back to building vs. assigning CFLAGS . . . > >> > >> Directly assigning CFLAGS (CFLAGS= or CFLAGS+= style) can be problematical, > >> with that definition possibly overriding internal definitions by preventing > >> internal CFLAGS?= usage from picking up material or other such in contexts > >> one is not trying to control (nested contexts). I have run into such issues > >> historically. > >> > >> Here we are trying to control something normally supplied internal to the > >> build infrastructure, only in places where that stable/12 infrsuctcture's > >> normal > >> > >> CFLAGS?= -O -pipe > >> > >> would have done the assignment. We do not want to be adjusting other > >> contexts that do things with CFLAGS ( including, possibly, other uses > >> of -O in nested contexts). > >> > >> We probably also do not want to analyze the whole build infrastructure > >> looking for places to worry about inappropriate overriding and figuring > >> out what to do for them. > >> > >> Such also applies to using, say, CFLAGS.clang+= that would add > >> separate text to the command lines without disabling the CFLAGS?= usage > >> (for example). Then things get into order of conflicting options and > >> which "wins" and if that is always an appropriate result. > >> > >> So the only simple technique that I know of is to change the actual file > >> ( share/mk/sys.mk ) that has the above line. That limits itself to the > >> correct context directly. Only the share/mk/sys.mk copy in the file system > >> needs to be changed: no need to have, say, a git branch of your own (unless > >> you want such). > > > > Looking at /usr/freebsd-src/share/mk/sys.mk I don't find a CFLAGS.clang line. > > I was not trying to imply that you would find such in FreeBSD files. (There > is code that enables such notation to be used.) > > I have such .clang notation in use in my own files, not in modified FreeBSD > files. You likely do not want the self-support tradeoffs involved, including > the build environment knowledge gathering involved for figuring out when > the notation will work sufficiently for your purposes. > > > There is a snippet containing > > .if ${MACHINE_CPUARCH} == "arm" || ${MACHINE_CPUARCH} == "mips" > > CFLAGS ?= -O -pipe > > .else > > CFLAGS ?= -O2 -pipe > > .endif > > > > Indeed, I don't see anything that distinguishes armv7 from arm64. > > True. armv7/armv6/arm64 have been using -O in stable/12 and now > use -O2 in 13. (But -O means very different things in stable/12 > vs. in 13, because of the different clang versions involved.) > > 13 uses -O2 for everything now. The reference to the armv6/armv7/arm64 > change is: https://svnweb.freebsd.org/base?view=revision&revision=350210 > which shows in the sys.mk log as: > > Revision 350210 - (view) (download) (annotate) - [select for diffs] > Modified Mon Jul 22 10:17:59 2019 UTC (17 months, 1 week ago) by manu > File length: 8664 byte(s) > Diff to previous 335452 > arm: Use -O2 instead of -O as optimization flag > > When using Clang -O is equivalent to -O2, change it -O2 to make it > consistent with other platforms. > > Reference: > https://clang.llvm.org/docs/ClangCommandLineReference.html#optimization-level > > > Submitted by: Daniel Engberg (daniel.engberg.lists@pyret.net) > Reviewed by: emaste > Differential Revision: > https://reviews.freebsd.org/D21021 > > Note the implication of the description: at the time -O and > -O2 were equivalent for armv7/armv6/arm64. That is no longer > true of clang 11 and FreeBSD 13. > > Later ( -r366664 ) mips was also changed. That is when having conditional > logic was removed. By this later time frame clang 11 had changed -O to > mean -O1 instead of -O2. So to get the historical standard output, -O2 > had to be used instead when clang 11 was doing the compiling. > > > > Am I looking at the wrong file? > > That is the correct file. armv7 was not the only type of arm target > changed: armv7 is just an example for the change. > > The earlier code that you quote is the same text from the same file > that I showed in a git diff that showed the change I made to do my > test. It was a one character addition for how I did it for my test. > > As of mips also changing, 13 had deleted the first 3 lines that you > show and the .endif line as well. (Such is equivalent to what I did > by instead adding one character to what stable/12 had there.) What > 13 did should be fine for your use if you want to do such: equivalent. > > > /usr/freebsd-src is the stable/12 > > build directory, cloned by git. Or, is that the problem, that armv7 > > and arm64 are treated the same way? > > arm64 builds clang.full either way in FreeBSD 13 but -O2 will produce > faster LLVM toolchain programs. > > armv7 does not build clang.full when -O is in use on FreeBSD 13 and > -O2 can work. When FreeBSD 13 builds stable/12 it uses stable/12's > option to build clang.full , and that option is still -O as things > are. Thus FreeBSD 13 does not support the operation as-is. > > >> > >> I've run into this before and have used my own share/mk/sys.mk variant > >> as needed. I actually use CFLAGS.clang+= and the like for something but > >> would not use it for this -O2 vs. -O issue. > >> > >> If you still try your own CFLAGS assignment, include the -pipe as well: > >> > >> CFLAGS= -O2 -pipe > >> > >> Otherwise the -pipe will end up missing. > >> > > > > Are you referring to /etc/make.conf? > > WARNING: /etc/make.conf and /etc/src.conf are not limited > to buildworld buildkernel use. For example, port builds > can also use the likes of /etc/make.conf . Thus one ends > up managing the content of those files as one switches > what type of thing is being built. (The port build > technique matters here, I'll not get into the details.) > > Yet, even for just buildworld buildkernel contexts: > > As an illustration of why such is bad: if CFLAGS already > has a value the use of CFLAGS= would destroy the value if > executed. (Is /etc/make.conf only included once for over the > whole buildworld build kernel? At exactly which stage(s) > relative to share/mk/sys.mk ? Do you want to analyze such > things?) > > By contrast: > > CFLAGS?= -O2 -pipe > > avoids that issue but then what you get is dependent on which > CFLAGS?= happens first in the detailed ordering of operations > whenever /etc/make.conf is involved/executed. > > > > That seems preferable to tampering > > with makefiles. > > The point of my notes was that, in this type of context, that is > not necessarily true. > > I have reported that I have had example problems controlling -O2 > use (or similar) and what my investigation indicated to me as what > was simpler that would work --and that is what I use when I do not > want to do what FreeBSD does for -O2 type options. (I do not > normally build stable/12 or other such and so the issue does not > normally show up for me in modern times.) > > Hopefully the notes will help if you try things and have problems. > But the simplest thing at this point is to add the one character > to stable/12's share/mk/sys.mk ( until/unless you get someone to > MFC -O2 use into stable/12 ). That seems pointless as I now understand the situation. Nobody has a practical incentive to compile old OS versions with newer ones. I tried it only out of laziness. When the arm64 Pi3 came out it seemed likely that FreeBSD's support for 32 bit arm would erode. As LLVM gets larger the erosion can only speed up, particularly for self-hosting. I wonder when armv7 will be "too small". Your notes and comments have been profoundly enlightening, Thank you, bob prohaska From owner-freebsd-arm@freebsd.org Wed Dec 30 19:07:19 2020 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 53E394CC77E for ; Wed, 30 Dec 2020 19:07:19 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5glB2BySz4YD4; Wed, 30 Dec 2020 19:07:18 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mail-ej1-x62f.google.com with SMTP id g20so23058037ejb.1; Wed, 30 Dec 2020 11:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bPjKrgOsfWpJJJw8t3LRLxdpKOyiFglBG7R8Cu8cTfs=; b=HJDkDSey3B5RsWnUCgqkW1dTPJCeyA2Fi8RI9MkCizo/BcAx92/ew7RRWmSGspWedt ekDcMbnTp91ATtTSv+E8fmwq1WMg+7ct7UdUOK6AWA3S/yacEtMGznCPtS9gOxqpM3fd f+Cl5JW3TUv1J6T0AdENzfo8Dq9fJsPP/87IQmaosTVvBTNvOAQ3F0C9mFPcRIdsDbZa eB3PLMSP+W2Cib7XPa66EG1TmfzHUU20QmYH+NYU7xJ18rTEN+N6qdHJyI9geWkewlri Tkfya4gQoPRP9tCbGBTTLFjRIKM4X8iZ2a7fP7I911JSEnsDAxONAoUYZumKUoywSR1C OXIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bPjKrgOsfWpJJJw8t3LRLxdpKOyiFglBG7R8Cu8cTfs=; b=tPzDxg4uoKQOt3oy8MCvuKTrDEKcAahzviI9F8eyw8fKj0Jcg6BEZHtlhUty4DW0Xy 0fSPhPx109mPzKt8w38ZD+tpjX0UF/se6ngkfa3JlB7VJB8ss7nimxPHKupAAa69SFz8 uzaSrmb+tW8G2eKrThDftQoeohiF3EqFpr8KxrDog5YyY+IOLPCqIjiD3h0AJSncDis3 RmBFKK4/MZk1wY9POGcfn/TXmf3gNUsC39NNqEZuRlBmap8zQf5ZAJq3sdE6HwrEI+Op fjCWSpiDW0h65hwT3/ChQt3O+aYGuRoRYwDaGREo9y4rnIo1UsFKAEmZyUoe3G7qDTzW aV6A== X-Gm-Message-State: AOAM532xdjURNv6dQnV6MBSWgkj4aizmtwSfyio4BFo4GfyNHz14LOM9 Jte4QvOv6Hj1D6HTMMFwUJNzd92mk3GNLA== X-Google-Smtp-Source: ABdhPJyNozF0fiLskIxMcmBn07uSxClQpHFwpDLSNrRPV9sANszIzWh90/gsjp2c+kZ1ClOwUsrGvA== X-Received: by 2002:a17:907:1004:: with SMTP id ox4mr49553254ejb.240.1609355236724; Wed, 30 Dec 2020 11:07:16 -0800 (PST) Received: from mac.deepcore.dk ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id z13sm12028426edq.48.2020.12.30.11.07.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Dec 2020 11:07:15 -0800 (PST) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Message-Id: <23CCE944-C9F0-42C9-8A93-DAC312FE01E2@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: FreeBSD-13.0-CURRENT-arm64-aarch64-ROCKPRO64-20201210-7578a4862f0 broken ? Date: Wed, 30 Dec 2020 20:07:14 +0100 In-Reply-To: <6784D541-8FED-4753-8631-B36886508165@gmail.com> Cc: Ian Lepore , Daniel Engberg To: freebsd-arm , Emmanuel Vadot References: <4434862ed87c21113fb7f98636fe4694d73856ce.camel@freebsd.org> <0D6FCA87-F101-4AA0-A1BF-6EDBA003BC9F@gmail.com> <87B7940E-119D-4C7F-AB9D-0C78E7F8D3A3@gmail.com> <20201213180746.1224166dffb81cb6770ff80d@bidouilliste.com> <6784D541-8FED-4753-8631-B36886508165@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Rspamd-Queue-Id: 4D5glB2BySz4YD4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=HJDkDSey; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::62f:from]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::62f:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=utf-8 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: Wed, 30 Dec 2020 19:07:19 -0000 > On 14 Dec 2020, at 22.45, S=C3=B8ren Schmidt > wrote: >=20 > Went to the official u-boot sources and tried the newest shiniest = 2021.01rc3 and it behaves a little bit better, it will boot 1 out of 3 = times :) >=20 > Probe looks like this now: >=20 > U-Boot TPL 2021.01-rc3 (Dec 14 2020 - 23:17:52) > Channel 0: LPDDR4, 50MHz > BW=3D32 Col=3D10 Bk=3D8 CS0 Row=3D16/15 CS=3D1 Die BW=3D16 Size=3D2048MB= > Channel 1: LPDDR4, 50MHz > BW=3D32 Col=3D10 Bk=3D8 CS0 Row=3D16/15 CS=3D1 Die BW=3D16 Size=3D2048MB= > 256B stride > lpddr4_set_rate: change freq to 400000000 mhz 0, 1 > lpddr4_set_rate: change freq to 800000000 mhz 1, 0 >=20 >=20 > The exact same as before. There is no difference in output from the = working boots to the failing ones. > I=E2=80=99ll get on with adding some debug to what parameters get set = during memory setup etc. > However I have this gut felling it is timing related and my board = might just be too slow/fast for some operation that the ayufan version = does slightly different (it boots every time). >=20 > Anyhow, when it boots it runs rock stable, it builds worlds etc with = no issues.. OK, I got a little further, it may not be memory related after all, from = dozens ff boots with same u-boot etc I found that those that fails sees = the SDcard like this: mmcsd0: 16GB at = mmc0 50.0MHz/4bit/2048-block And those boots that works: mmcsd0: 16GB at = mmc0 20.0MHz/4bit/2048-block So it suggests that either our code for setting the SDcard speed I flaky = or marginal or the SD card / my pinebookpro is... However the exact same SD card can boot netbsd/openbsd dozens of times = with no issues at all with 50MHz timings. Back to debugging :) -- S=C3=B8ren Schmidt sos@deepcore.dk / sos@freebsd.org = "So much code to hack, so little time=E2=80=9D From owner-freebsd-arm@freebsd.org Wed Dec 30 20:00:33 2020 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 822644CDA4C for ; Wed, 30 Dec 2020 20:00:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.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 4D5hwc3XRlz4bdf for ; Wed, 30 Dec 2020 20:00:32 +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=1609358429; bh=aG3sp9ey8ihP3bfcxRag2G1O2V/MFA+rVvPIxUSIFEP=; h=Subject:From:Date:To:From:Subject; b=NpiMXtWrFFjp2e++PtRxJlGupTt+dL1WPvFzmwXSgSWq4nEKQvMUmUnSCCxgXO+acV/f+aJbNn7xIHX+chb2NiwgqPzchQjLS5NlPfbD6Z/TxVjT5FKYymY6QurcQ0A7OC8HH4uX31wRH3g7OOQBqjihL7Sv3QnnC+zhu92LvPvBbjnYuwfxjK49tTznccmRb+HNW4czp25H0xosRyikOSgOAGRNzyA58UAL8lP9WvAca6m7UNFjwuju0NizzV9LsF7L4TrSPbfB5URMTcMduO62dPjJTy5sjmQFhTL7M71kp7QjR0dK/AUNecIzYZKTFuKvN1xY8zSh+bNK2QBaXw== X-YMail-OSG: 7TmsqKYVM1mJ5yceoK0neHA.q46y03NcxWo7Wa_8vHze2SiEked1XdPrL.hrP1e FsHhRVixO6_K3z26oNl9Be5BD.1n3ZA.Hlp9u11a4Sg6Z_bSUiGhcrdOW2Idr.ferTU5tsKptfD2 fwq7NQ3XQCrKsAtUkThKUSEOE.b8wDkFcKZTVqqLnP0VPRp_XgKSym8niKrUMygR9kuXIZFCkbTp qKeWvKysx__ig_HC52QJnZLnSOeXf3KzaCD0x6LDk8H1RKXCBPQ2kklQ50l1EiwCsT9Wf9Vk7C5d 9NbhLRbWbn3DCZLRE.vH1U.ZwsifDw3QUeA4Pg6_41zC1CmYU3GrF549cto.rdCyfv5lNJgy6Qxt k5f5_31M1rIfeSQKO.YWySOYJ.nuvDeYt3eYFiwAkbWKflqNqy2RkrrxwePSoysduqjWaPPR8Fu6 DCNOjiraXTOWy5DYQlw8UX5BZ5e.w1KX87PewJ92_U2_GzlW8DzO5Qg8t3EKYdyPf_xbPn8foW7r UbKFLy7sHXMJLZwKBMMh90zlfpscQ_OzOvQy4Rtya9U1lYW8VgtVbfP4MIhyN8KgHqBYEXRoZDi2 YDyLqAlqKqKhwtYYKFuLf3EOgwi8lwMi11m_Zw7CQBHTdX0uhBPvxPwllguGAOmzivZGjy57V_1x wI1LPT4Oqw5AtplGz06xFOcoDPnCYi_yYCSUOgVYtbD0GUAcY5VnzOOBZ7SsYyUxSFdvC0V0T1kV cEzGsgvXMCa3pjrhVdMX_n_.oTc.YluRfFtt5llx_FuwpIoO4FJvWGAVuc.Wn1HOeosF4Aqcxg7r cZsiv7EMp7OzOE3xsUObBEuB.wAdlCPxp0VEj082C5ERKPhVH8ZkMPPOu2ib7UAlgzO3J3edU3C6 rbKMxKx7ZEP8ttQCXTSaq8RehPP2grCYWtTP8GSVMHrbEQDL.a99_QTT6Fr9k0imETLY8ka5BSSr R5RmAQjpS4jrB8y_K_b8FVpPf1PSZr9m1xB59K0SYVHyzuIyknw_e7HtUzLUBgXxNntP5SABLGM7 1Dz8hjCUbIw_YYvZ2cPbkxMzO4TNWaRjfTi19dNYIb9rIvHuyf_ibRP7DSS5BwwYphuv1TaEDbgT pJG.v4R2PS.0SS4V0SkhlDHu6FFn1364RoepjkAn4Du8Dti1IBKak.Gc6bBG2HUEoIfvInCr2._M lae5i8zGHYwu9dyse3RpJQ2tOoxI8Um5lSy9L.i9KDTAleZT7eC6G.TBW.o63GWUASwfwngjRzFr bnijevM47S4du65kMdJJi6KMm7eqr6q5p2U2IKaB2_rXImBZhJMflVx_lnZYIrWZyIKv_o.1_DBS S3V9B7Ybv0iejvtKdThd7bIf1Gi.tXsWEqselvQQh3yupgAgOeWlKgEtmUcztApixdkjOcNhicPc ABVvVFetvLmAs2mNcqc4_nebVSZU.xW12R4Ugd9tg2Zgho_t5oaCk5S0jNx4A4PGK4IJ5g5iWptj OYQFEapNYXAcpLl7tcHhwizWri6A8KU5KURVulC7qT32bqUz8BbBCkLx1jGab8W6dcia5FA7Ce1_ FCpVFMOEp7kY_2kHwARKHj6HbWVZxf.FM42z78ltvq5RTXK.oYD5dFZw.mM_jcN0XqdtaocKTBhM qNiM9v9aG5ijUEh2N8p3omYH8vTBFh4sHOe0g6Tl4vvtb1qSTm6cf3.hvwIyieJw_DjvB0A1s.zV LQeDg1xEpP.bpbpc0Zfr7FVrH1Se17KaVMPqfa6.6vcSUcQyRqdXDlHRBeQ38N525AmSs9WIop2F 3gYCKGQtzCBGTH3wdO.170nvDaB9V5BOoCix4onHqNUdtBO7JV9lzCx87KtzOqCQ9N.cw18y49Ce mS2r3yyJ8BqQ8wKfjTdKWFmyO6DEws0l4nuk27Ut3BLWTPhxiOqE0j6YlEdZdSK57yuV7shbFrk9 9PTfGDV7eaVqCbiqwz6D7ZR8082xoTV.fzUKQb6RXgDWs5OQk4NRsrVuWYmVP7B1TSv1Z3iH78cQ trN_UDpDxh0lhg2Kj3LJdipP43NMYzjMILLVZuHAEZaVmtUz0XXaNCLiOr0cdyoNeSXyJ12yI3Vm K0TP4DlhBvffgW4ZNVW4y0IELfJ5ugfWB7ekdwaDkGz2Hvzieuu_z8lBl5R6Y0niEZPSs2d889sh 1GVQQ.HOY0YGwQyaYwLOjJKQykxPdJH_1mlY_VH4Ax6lrmvzVVvhlsKVPO6qt4_.pek4sjvF199F 4fUgVPnQqmlpMS1NmgiLkjp3Fgev5EXvsgXb.65bLdh7CcD9FU5oqLzKENfNLCiMvfIBp59A1k1_ 6TRTkmzjpsE5mU.4ym5kQ0Z.XIULnYmQDV_hDW6.I64bZeclcHwVQeO0DRCvp3HS2JFs_6YZtKav x_yRo9rXr7cgHZaNwIJ2JHBHq79IHM7bD_mOIElAZ516_mz8A6I03MhzbmYhH7EL6n8gwTvcGTDJ hogGtOMXgCDttaUwb2NZWklbDZLme Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 30 Dec 2020 20:00:29 +0000 Received: by smtp414.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6d58e047e3d8d9fe90b483689fdd7905; Wed, 30 Dec 2020 20:00: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: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <20201230183052.GA56823@www.zefox.net> Date: Wed, 30 Dec 2020 12:00:23 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0160302A-B566-4B9E-A9BB-48BFC1043FD4@yahoo.com> References: <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> <67E8786A-79E7-409A-BF4D-738F4FEB5EFF@yahoo.com> <20201229235701.GA49529@www.zefox.net> <20201230035447.GA50440@www.zefox.net> <20201230183052.GA56823@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D5hwc3XRlz4bdf X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.89 / 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(-0.39)[-0.389]; 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.83: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.83:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83: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, 30 Dec 2020 20:00:33 -0000 On 2020-Dec-30, at 10:30, bob prohaska wrote: > On Tue, Dec 29, 2020 at 10:49:09PM -0800, Mark Millard wrote: >>=20 >>=20 >> On 2020-Dec-29, at 19:54, bob prohaska wrote: >>=20 >>> On Tue, Dec 29, 2020 at 05:28:55PM -0800, Mark Millard wrote: >>>>=20 >>>>=20 >>>> On 2020-Dec-29, at 15:57, bob prohaska = wrote: >>>>=20 >>>>> On Tue, Dec 29, 2020 at 02:50:07PM -0800, Mark Millard wrote: >>>>>> . . . >> . . . >> As things are, you are out of the bounds that FreeBSD currently = supports >> when you try to build stable/12 on an armv7 FreeBSD 13 (or armv6 = FreeBSD >> 13) with the built-in toolchain (counting stable/12's Makefile*'s). = (The >> same likely applies to 32-bit powerpc.) >>=20 >=20 > It's worse than that: I'm trying to turn back time. I wanted to test = the > stable-12 upgrade path for armv7 and used the 13-current box because = it was=20 > handy and expected backward compatibility. Makes no sense in the = context > of an OS. It makes more sense to wait for stable/13 to emerge and test = that, > given that 13-current seems to work with armv7. The handbook warns = against > crossing major versions, doing it in reverse compounds the trouble, = since > developers have no reason to expect anybody in their right mind = _wanting_ > to do it.=20 The official armv7 builds are done via creating a 12.2 release jail that does the 12.2-STABLE build --on a machine that may have been booted via a more recent OS version. (I'm not sure what butler7.nyii.freebsd.org is booted with.) In fact it is also a cross build running on 64-bit = hardware, not running on armv7 hardware, not that such is essential. (I looked at: = https://ci.freebsd.org/job/FreeBSD-stable-12-armv7-build/lastBuild/console= Text .) A somewhat analogous chroot context could be used on the RPi2. You could get materials from: https://artifact.ci.freebsd.org/snapshot/12.2-STABLE/r368787/arm/armv7/ base.txz possibly: src.txz possibly: ports.txz possibly: base-dbg.txz and expand the tar(s) into an initially empty directory tree. chroot to that directory tree. mergemaster or such may be needed. Have 12.2-STABLE build itself in that chroot context. Install from the build to some media the RPi2 can use for booting (update or from scratch). Use the media in the RPi2 v1.1 to boot 12.2-STABLE . (You may want to provide a different source tree than is in src.txz . You might want to mount_null a source tree into the chroot area before doing the chroot.) There are details I've not covered, like having /dev ( and /dev/null ) show up in the chroot area. I referenced an artifact.ci.freebsd.org snapshot because neither of: http://ftp3.freebsd.org/pub/FreeBSD/releases/arm/armv7/ nor: http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm/armv7/ has such armv7 .txz files available. (arm64 does have such in the analogous places.) >> . . . >> That the armv7 (/armv6) always has a "small" address space is a = hardware >> issue (instruction set architecture), not software. That -O1 (and = clang >> 11's -O) requires more than 2 GiByte per-process spaces to build >> clang.full is the consequence of (mostly) LLVM choices. FreeBSD = chooses >> to be LLVM based and FreeBSD 13 chooses to be LLVM 11 based (until = LLVM >> 12?). >>=20 >=20 > Given the continued "expansion" of LLVM, it seems likely that before = long > it will become incompatible with armv7, despite the use of = optimization.=20 > Does this seem correct? I've not checked how big of a user process is involved in linking clang.full when -O2 is in use. I do not know how much room that there is for more in that kind of context. >> . . . >=20 > That seems pointless as I now understand the situation. Nobody has > a practical incentive to compile old OS versions with newer ones.=20 > I tried it only out of laziness. The official technique is less direct than what you were trying, in that it uses a 12.2-RELEASE jail to build a 12.2-STABLE . This avoids issues like -O in clang 11 not matching -O in clang 10, even if the host machine was booted with 13-CURRENT. Something similar can be done with a 12.2-STABLE armv7 snapshot from artifact.ci.freebsd.org . That would stay in the supported range of activities/relationships when used on the RPi2 v1.1 booted with 13-CURRENT. > When the arm64 Pi3 came out it seemed likely that FreeBSD's support > for 32 bit arm would erode. As LLVM gets larger the erosion can only > speed up, particularly for self-hosting. I wonder when armv7 will be > "too small". I do not know. =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 Dec 31 10:47:14 2020 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 3F7D74BC7DA for ; Thu, 31 Dec 2020 10:47:14 +0000 (UTC) (envelope-from luizgustavo@luizgustavo.pro.br) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 4D64bj1yfvz4b5Z for ; Thu, 31 Dec 2020 10:47:13 +0000 (UTC) (envelope-from luizgustavo@luizgustavo.pro.br) Received: by mail-ej1-x62b.google.com with SMTP id 6so24970714ejz.5 for ; Thu, 31 Dec 2020 02:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=luizgustavo-pro-br.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=aladkUQhx4/EHjuYKAVCDKJOKlvbZVIOEPEezWyeJHM=; b=hw69ej3OMKLPfHi73YBcpcqB5qCe1dyHURGtzEvEai4dckwQYia+F4jMvFlK96/Ut6 +MgqrW4VV0PfP8OZpS3FB8gBMTYlYHAeJuRUxe3pu6oM59qeybmr1D01BdPYBNxQOYgv TzlcRgA0ApEN7x6Gmj05VQXN5ibDdSCz+I6dHU3R2AvaM9Ch+W/2FY82/CaeVCrfPYHD SpcHe+55mHpu3DRSkHhXO/BAu5V1xr83mZG/zbkk4Lu85B2X1eag9iAJFyUB/tt6Kavk UF6Uvd8XoY2ec1auIWyRcJaNVqhRP0Z72CPvQ5yixtLja9623bFn5s59q+2sfpD1Z58i 6hpQ== 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=aladkUQhx4/EHjuYKAVCDKJOKlvbZVIOEPEezWyeJHM=; b=hX1VYm6iuiSA57JeBKnJWEP4x5r9f4gFQ32CsNSjcms7wM1O8pplAQGyiK8h3wMTHL Cy8YzlV6nP6QXyC2kRAywOqS2R5+rNEFMwA6Dq8s8bl/x6SF+2zlkb6mUmPnJ27Lg6E1 XsEKEEwXf2bqW0Y9rF9XAckj4aqQuN3K3qOd7GDS1ec2t9QJ9MMMoh42wqLej7U7D/wg 08U9WhrRrwMtVZobW03M/WO8QlDWTrPMgAn8cZGwaTYkBGX9OHtkVG4th+dtoKPY2zMo ms52VQuOWJ+paGmPw6l4smb11wg7u38NXYvSrUs72+hdsVKDsY+sZvywIeg2KbfMer1x /hYQ== X-Gm-Message-State: AOAM531aJ06RB3sceytuEHwFc+WgzQSrwPdxqpw145hCo1wPoe28hf9n mfxiBloYeT6XLeh6s1jYDDGWOwQSoiGpqHR7RVSM7oBRAWTaIA== X-Google-Smtp-Source: ABdhPJwVXwxUgdlh4BZgKEjEd9Go+ITgtHMQdtevxP71occDWpZTjHWJ2xs9/JaIISQGUhxyBnwXWoXj6JGq4dtJh84= X-Received: by 2002:a17:907:4271:: with SMTP id nq1mr11262049ejb.358.1609411631589; Thu, 31 Dec 2020 02:47:11 -0800 (PST) MIME-Version: 1.0 From: "Luiz Gustavo S. Costa" Date: Thu, 31 Dec 2020 10:47:00 +0000 Message-ID: Subject: NanoPi R2S RK3328 with 13-CURRENT (rock64) To: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 4D64bj1yfvz4b5Z X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=luizgustavo-pro-br.20150623.gappssmtp.com header.s=20150623 header.b=hw69ej3O; dmarc=none; spf=pass (mx1.freebsd.org: domain of luizgustavo@luizgustavo.pro.br designates 2a00:1450:4864:20::62b as permitted sender) smtp.mailfrom=luizgustavo@luizgustavo.pro.br X-Spamd-Result: default: False [-1.44 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[luizgustavo-pro-br.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::62b:from:127.0.2.255]; DMARC_NA(0.00)[luizgustavo.pro.br]; DKIM_TRACE(0.00)[luizgustavo-pro-br.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.94)[-0.937]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62b:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::62b: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: Thu, 31 Dec 2020 10:47:14 -0000 Hi list ! I just received my board and started playing with my toy: https://asciinema.org/a/381979 The whole process, as soon as I can I will detail the process in a github md and explain the steps. First lab with Freebsd on it, I had to use another u-boot from armbian to run a freebsd image. At least I have a network on the first ethernet, now it's to see why the USB didn't go up. Have a happy new year ! Luiz Gustavo Costa http://www.luizgustavo.pro.br From owner-freebsd-arm@freebsd.org Thu Dec 31 12:15:40 2020 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 0CD4F4C0134 for ; Thu, 31 Dec 2020 12:15:40 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (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 "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D66Yk31cYz4hZ6 for ; Thu, 31 Dec 2020 12:15:37 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Thu, 31 Dec 2020 12:15:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1609416928; bh=+//1JSOoNYx1uxKRPFkY7sGCkf/AQq42Tz5FSwTRVFQ=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=gYKm2sjO9ERJb3txiMMuCkDCecNMMvXjcjYzhejMcaEojURmLrkmSCw1QW9jAzK76 4vvYJuNcYLdGPNR9gMStFNVJ59zm1NIE6fdVXuSiDujR3vhPuhGkTC09hQBoltB4ZE r0xNiyTzZJX1TjwHnlak4xliL9gjZDz+oMm83uKI= To: Andrea Brancatelli From: Dan Kotowski Cc: freebsd-arm@freebsd.org Reply-To: Dan Kotowski Subject: Re: VirtIO-Net not correctly handled Message-ID: In-Reply-To: <7849A0D0-7307-4432-B0B0-6005C7062BBA@schema31.it> References: <7849A0D0-7307-4432-B0B0-6005C7062BBA@schema31.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4D66Yk31cYz4hZ6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=gYKm2sjO; dmarc=pass (policy=none) header.from=a9development.com; spf=none (mx1.freebsd.org: domain of dan.kotowski@a9development.com has no SPF policy when checking 185.70.40.131) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-1.80 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[185.70.40.131:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[185.70.40.131:from]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.131:from] 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, 31 Dec 2020 12:15:40 -0000 > I could not find any way to get it to boot. :-( > > Machine on, white block upper left, nothing else happens. > > Inviato da iPhone > > > Il giorno 29 dic 2020, alle ore 19:14, Dan Kotowski dan.kotowski@a9deve= lopment.com ha scritto: > > > > > Hello everybody, > > > > > > after tuning CPU (1 cpu only) and Ram I was able to do a full install= of > > > > > > FreeBSD 12.2 in a Parallel Desktop VM running on an Apple M1. > > > > > > Everything seems quite in order but I can't get the network card to > > > > > > work. > > > > > > Parallel Desktop is presenting a virtio-net card and pciconf is > > > > > > correctly listing it but the driver doesn't hook to it. > > > > > > Here you can see a screenshot of the situation: > > > > > > https://www.dropbox.com/s/hv6g8btjm45m0mh/Schermata 2020-12-29 alle 1= 6.42.10.png?dl=3D0 > > > > > > [sorry if I keep posting screenshots but there's no console integrati= on > > > > > > so I can't copy and paste...] > > > > > > Any suggestion on how to get it working or investigate deeper? > > > > What about with 13-CURRENT? There's a lot of aarch64 work going on in 1= 3 that is unlikely to be backported to 12, so it'll be best to focus effort= there. > > > > --Dan Kotowski Can you do a verbose boot of 12.2 and post `/var/run/dmesg.boot` to https:/= /dmesgd.nycbug.org/index.cgi ? Also if you can figure out how to copy the output of `devinfo -v` and `pcic= onf -lv` somewhere shareable like a github gist or pastebin, it might help = as well. --Dan Kotowski From owner-freebsd-arm@freebsd.org Thu Dec 31 12:36:31 2020 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 081044C0B11 for ; Thu, 31 Dec 2020 12:36:31 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from stricnina.schema31.it (stricnina.schema31.it [IPv6:2001:470:28:12b::99]) (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 "stricnina.roma.schema31.it", Issuer "stricnina.roma.schema31.it" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D671m4L9Bz4jyw for ; Thu, 31 Dec 2020 12:36:27 +0000 (UTC) (envelope-from abrancatelli@schema31.it) Received: from smtp.schema31.it (localhost [127.0.0.1]) by stricnina.roma.schema31.it (8.15.2/8.15.2) with ESMTP id 0BVCaCit043622; Thu, 31 Dec 2020 13:36:13 +0100 (CET) (envelope-from abrancatelli@schema31.it) MIME-Version: 1.0 Date: Thu, 31 Dec 2020 13:36:07 +0100 From: Andrea Brancatelli To: Dan Kotowski Cc: freebsd-arm@freebsd.org Subject: Re: VirtIO-Net not correctly handled Organization: Schema31 s.r.l. In-Reply-To: References: <7849A0D0-7307-4432-B0B0-6005C7062BBA@schema31.it> Message-ID: <34869b4799a00a1ddb0d9b69d94a7106@schema31.it> X-Sender: abrancatelli@schema31.it User-Agent: Roundcube Webmail/1.3.15 X-Rspamd-Queue-Id: 4D671m4L9Bz4jyw X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:28:12b::99:from]; R_DKIM_ALLOW(-0.20)[schema31.it:s=gCloud]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; HAS_ORG_HEADER(0.00)[]; SPAMHAUS_ZRD(0.00)[2001:470:28:12b::99:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[schema31.it:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[schema31.it,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 31 Dec 2020 12:36:31 -0000 On 2020-12-31 13:15, Dan Kotowski wrote: > What about with 13-CURRENT? There's a lot of aarch64 work going on in 13 that is unlikely to be backported to 12, so it'll be best to focus effort there. > > --Dan Kotowski Can you do a verbose boot of 12.2 and post `/var/run/dmesg.boot` to https://dmesgd.nycbug.org/index.cgi ? Also if you can figure out how to copy the output of `devinfo -v` and `pciconf -lv` somewhere shareable like a github gist or pastebin, it might help as well. --Dan Kotowski I was able to attach an USB ethernet card to the VM and it's working, so I can give anything you want... Here's the DMESG: https://dmesgd.nycbug.org/index.cgi?do=view&id=5839 Here's the PCICONF/DEVINFO: https://gist.github.com/skeyby/44cefbab8c653376e23a81162be6eab5 --- Andrea Brancatelli From owner-freebsd-arm@freebsd.org Thu Dec 31 12:49:25 2020 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 A7DE94C0CC9 for ; Thu, 31 Dec 2020 12:49:25 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 4D67Jh2l4Nz4kHK for ; Thu, 31 Dec 2020 12:49:24 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mail-ej1-x630.google.com with SMTP id d17so25223072ejy.9 for ; Thu, 31 Dec 2020 04:49:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=SgW7s2Y8fFi5JwS9O7Apttv7/ty80i5eoTOAsmalkV8=; b=gTTvXfTIgdpgYIhLZLyIT+EhUKCXbruVXDWzydnCibJKfmP/t2WTzhURSSo52T5jFm lG2PYj5cu/2SVPJdknoCJjq38wXBRfF1FUw8VpiIWNp1z7+8MbpBVNjYEbxB1aaKTh8x SZ3MF77I8n9k31eHbk/5dyjbpffy41onldGfEh9XZv1Ni/OCMgiL8LzgTAMZiU2SgmxB XIhtBMtrvOweh6QixTCxMfcITvfx5VU9Lso6HUr78olzwG9wmLyUWbXSUaE5AqWkUlPZ iuHIWANdMD1qugN4L1qSnihB5Z7Mp0PVm3uXj3TOXjc8X7Fy3Y2AZoEIVgM5CNL8RVXi 1NQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=SgW7s2Y8fFi5JwS9O7Apttv7/ty80i5eoTOAsmalkV8=; b=eNO4gt62JnOQao7FHe3odrlAsHtOzulcPMimWs5D8eb7czx112Cnt7lslvMEUm+9eC hKXCg6gqtUtsx0XaH6JKcoYNTT6kviFfApvx+BdqSYe8c993YPXckelHdlgaO6x4+Y5k RPwZnLu+OBOHgsemNoR/9C1JvEw5AxEPTrakzvRYrvYD6J77UXqRQjlmgKUbPiZ1VBFY Ekq9ZhISS+XuFQ0w03xMtnNA9gH17REy/Cl2xlQNFH83YYY7Br/iyk9C5z2GXGUVmN91 dQQDqneUsd+nrPLZav9enXKaTA0eS1dsR3OYafaEFglGJxeOTztY429ShZqCJnZpw/vq iO5w== X-Gm-Message-State: AOAM5311pztizHU3gUngBcWgHeZiA7bPJ/qkJEJlRdeKqKkHZcnmMkTv jAMcsvw6AogMEJ6WS+tMXt8tnh3QI0I= X-Google-Smtp-Source: ABdhPJzeaYreiwC+Lbpci69zty9Kfr7BJPnhO1bK9VopedRxoK3bLyujAu4LvyMnznSfq4eSzD+FHw== X-Received: by 2002:a17:906:1955:: with SMTP id b21mr53024086eje.236.1609418961316; Thu, 31 Dec 2020 04:49:21 -0800 (PST) Received: from mac.deepcore.dk ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id oq27sm19775923ejb.108.2020.12.31.04.49.20 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Dec 2020 04:49:20 -0800 (PST) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: FreeBSD-13.0-CURRENT-arm64-aarch64-ROCKPRO64-20201210-7578a4862f0 broken ? Date: Thu, 31 Dec 2020 13:49:19 +0100 References: <4434862ed87c21113fb7f98636fe4694d73856ce.camel@freebsd.org> <0D6FCA87-F101-4AA0-A1BF-6EDBA003BC9F@gmail.com> <87B7940E-119D-4C7F-AB9D-0C78E7F8D3A3@gmail.com> <20201213180746.1224166dffb81cb6770ff80d@bidouilliste.com> <6784D541-8FED-4753-8631-B36886508165@gmail.com> <23CCE944-C9F0-42C9-8A93-DAC312FE01E2@gmail.com> To: freebsd-arm In-Reply-To: <23CCE944-C9F0-42C9-8A93-DAC312FE01E2@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Rspamd-Queue-Id: 4D67Jh2l4Nz4kHK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=gTTvXfTI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Spamd-Result: default: False [-0.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; 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::630:from]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; 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]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::630:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::630:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=utf-8 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: Thu, 31 Dec 2020 12:49:25 -0000 Hi gang On my quest on getting the pinebookpro booting again I think I can rule = out u-boot for now. Back on the u-boot-2020.07 where a -current kernel from late July/early = august would boot just fine a current kernel fails to talk to the SD = card, the only change to an up to date current is not setting the 800Hmz = cpll clock and that is known not to make any difference. Again the same SDcard works just dandy with net/openBSD also I 50Mhz = mode. 1 in 10 boots finds the card as 25Mhz and then it =E2=80=9Cjust = works=E2=80=9D. Any Ideas ? U-Boot TPL 2020.07 (Aug 09 2020 - 14:11:44) Channel 0: LPDDR4, 50MHz BW=3D32 Col=3D10 Bk=3D8 CS0 Row=3D15 CS1 Row=3D15 CS=3D2 Die BW=3D16 = Size=3D2048MB Channel 1: LPDDR4, 50MHz BW=3D32 Col=3D10 Bk=3D8 CS0 Row=3D15 CS1 Row=3D15 CS=3D2 Die BW=3D16 = Size=3D2048MB 256B stride 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2020.07 (Aug 09 2020 - 14:11:44 +0200) Trying to boot from MMC1 U-Boot 2020.07 (Aug 09 2020 - 14:11:44 +0200) SoC: Rockchip rk3399 Reset cause: POR Model: Pine64 Pinebook Pro DRAM: 3.9 GiB PMIC: RK808=20 MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from SPI Flash... SF: Detected gd25q128 with page = size 256 Bytes, erase size 4 KiB, total 16 MiB OK In: serial Out: vidconsole Err: vidconsole Model: Pine64 Pinebook Pro Net: No ethernet found. Card did not respond to voltage select! Hit any key to stop autoboot: 0=20 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... 80449 bytes read in 16 ms (4.8 MiB/s) Found EFI removable media binary efi/boot/bootaa64.efi Card did not respond to voltage select! Scanning disk mmc@fe310000.blk... Disk mmc@fe310000.blk not ready Scanning disk mmc@fe320000.blk... ** Unrecognized filesystem type ** Card did not respond to voltage select! Scanning disk sdhci@fe330000.blk... Disk sdhci@fe330000.blk not ready Found 3 disks BootOrder not defined EFI boot manager: Cannot load any image 1091484 bytes read in 123 ms (8.5 MiB/s) Consoles: EFI console =20 Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Dec 31 13:17:08 CET 2020 sos@newport.deepcore.dk) Command line arguments: loader.efi Image base: 0xf3dfe000 EFI version: 2.80 EFI Firmware: Das U-Boot (rev 8224.1792) Console: comconsole (0) Load Path: /efi\boot\bootaa64.efi Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,GPT,319e202c= -4b62-11eb-bf03-0800274503a7,0x8000,0x10000) Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,GPT,319e202c= -4b62-11eb-bf03-0800274503a7,0x8000,0x10000) Setting currdev to disk0p1: Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,GPT,319e202c= -4b62-11eb-bf03-0800274503a7,0x18000,0x1e7fd8) Setting currdev to disk0p2: Loading /boot/defaults/loader.conf Loading Kernel and Modules (Ctrl-C to Abort) .................................................. /boot/kernel/kernel text=3D0x2a8 text=3D0x512fd8 text=3D0x1467b4 = data=3D0x138930 data=3D0x0+0x52e000 syms=3D[0x8+0xb3730+0x8+0xbdce7] | Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x80e9000. EFI framebuffer information: addr, size 0xf7800000, 0x3f4800 dimensions 1920 x 1080 stride 1920 masks 0x0000f800, 0x000007e0, 0x0000001f, 0x00000000 ---<>--- KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2020 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #6 main-c255441-g4e4e43dc9e1a-dirty: Thu Dec 31 = 13:16:59 CET 2020 = sos@newport.deepcore.dk:/usr/home/sos/FreeBSD/embedded/aarch64-obj/usr/hom= e/sos/FreeBSD/git-current/arm64.aarch64/sys/PINEBOOKPRO arm64 FreeBSD clang version 11.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.0-0-g176249bd673) VT(efifb): resolution 1920x1080 real memory =3D 4158349312 (3965 MB) avail memory =3D 4033499136 (3846 MB) Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: WARNING: initial seeding bypassed the cryptographic random = device because it was not yet seeded and the knob = 'bypass_before_seeding' was enabled. random: entropy device external interface MAP f3f0f000 mode 2 pages 1 MAP f3f12000 mode 2 pages 2 MAP f6f30000 mode 2 pages 16 WARNING: Device "openfirm" is Giant locked and may be deleted before = FreeBSD 13.0. WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD = 13.0. kbd0 at kbdmux0 ofwbus0: clk_fixed0: on ofwbus0 simplebus0: on ofwbus0 rk_grf0: mem 0xff320000-0xff320fff on = ofwbus0 rk3399_pmucru0: mem = 0xff750000-0xff750fff on ofwbus0 rk3399_cru0: mem = 0xff760000-0xff760fff on ofwbus0 Cannot set frequency for clk: cpll, error: 22 rk3399_cru0: Failed to set cpll to a frequency of 800000000 rk_grf1: mem 0xff770000-0xff77ffff on = ofwbus0 regfix0: on ofwbus0 regfix1: on ofwbus0 regfix2: on ofwbus0 regfix3: on ofwbus0 regfix4: on ofwbus0 regfix5: on ofwbus0 regfix6: on ofwbus0 regfix7: on ofwbus0 regfix8: on ofwbus0 regfix9: on ofwbus0 regfix10: on ofwbus0 regfix11: on ofwbus0 simple_mfd0: mem = 0xff310000-0xff310fff on ofwbus0 psci0: on ofwbus0 gic0: mem = 0xfee00000-0xfee0ffff,0xfef00000-0xfefbffff,0xfff00000-0xfff0ffff,0xfff100= 00-0xfff1ffff,0xfff20000-0xfff2ffff irq 18 on ofwbus0 its0: mem 0xfee20000-0xfee3ffff = on gic0 rk_iodomain0: mem 0xff320000-0xff320fff on = rk_grf0 rk_iodomain1: mem 0-0xff76ffff,0-0xffff on = rk_grf1 rk_pinctrl0: on ofwbus0 gpio0: mem 0xff720000-0xff7200ff irq 71 = on rk_pinctrl0 gpiobus0: on gpio0 gpio1: mem 0xff730000-0xff7300ff irq 72 = on rk_pinctrl0 gpiobus1: on gpio1 gpio2: mem 0xff780000-0xff7800ff irq 73 = on rk_pinctrl0 gpiobus2: on gpio2 gpio3: mem 0xff788000-0xff7880ff irq 74 = on rk_pinctrl0 gpiobus3: on gpio3 gpio4: mem 0xff790000-0xff7900ff irq 75 = on rk_pinctrl0 gpiobus4: on gpio4 rk_i2c0: mem 0xff110000-0xff110fff irq 20 on ofwbus0 iicbus0: on rk_i2c0 rk_i2c1: mem 0xff130000-0xff130fff irq 22 on ofwbus0 iicbus1: on rk_i2c1 rk_i2c2: mem 0xff3c0000-0xff3c0fff irq 38 on ofwbus0 iicbus2: on rk_i2c2 syr8270: at addr 0x80 on iicbus2 rk_i2c3: mem 0xff3d0000-0xff3d0fff irq 39 on ofwbus0 iicbus3: on rk_i2c3 rk805_pmu0: at addr 0x36 irq 76 on iicbus2 generic_timer0: irq 2,3,4,5 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 rk_tsadc0: mem 0xff260000-0xff2600ff irq = 35 on ofwbus0 rk_usb2phy0: mem 0-0xff76ffff,0-0xffff on = rk_grf1 rk_usb2phy1: mem 0-0xff76ffff,0-0xffff on = rk_grf1 rk_emmcphy0: mem 0-0xff76ffff,0-0xffff on = rk_grf1 rk_pcie_phy0: mem 0-0xff76ffff,0-0xffff on = rk_grf1 rk_typec_phy0: mem 0xff7c0000-0xff7fffff on = ofwbus0 rk_typec_phy1: mem 0xff800000-0xff83ffff on = ofwbus0 cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpu1: on cpulist0 cpufreq_dt1: on cpu1 cpu2: on cpulist0 cpufreq_dt2: on cpu2 cpu3: on cpulist0 cpufreq_dt3: on cpu3 cpu4: on cpulist0 cpufreq_dt4: on cpu4 cpufreq_dt4: Not attaching as cpu is not present device_attach: cpufreq_dt4 attach returned 6 cpu5: on cpulist0 cpufreq_dt5: on cpu5 cpufreq_dt5: Not attaching as cpu is not present device_attach: cpufreq_dt5 attach returned 6 pmu0: irq 0 on ofwbus0 pmu1: irq 1 on ofwbus0 pcib0: mem = 0xf8000000-0xf9ffffff,0xfd000000-0xfdffffff irq 6,7,8 on ofwbus0 pci0: on pcib0 pcib1: at device 0.0 on pci0 pcib0: failed to reserve resource for pcib1 pcib1: failed to allocate initial memory window: 0-0xfffff pci1: on pcib1 nvme0: at device 0.0 on pci1 rockchip_dwmmc0: mem 0xfe310000-0xfe313fff irq 10 on ofwbus0 rockchip_dwmmc0: Hardware version ID is 270a rockchip_dwmmc1: mem 0xfe320000-0xfe323fff irq 11 on ofwbus0 rockchip_dwmmc1: Hardware version ID is 270a mmc0: on rockchip_dwmmc1 sdhci_fdt0: mem = 0xfe330000-0xfe33ffff irq 12 on ofwbus0 rk_emmcphy0: got emmcclk clock sdhci_fdt0-slot0: Hardware doesn't specify timeout clock frequency, = setting BROKEN_TIMEOUT quirk. sdhci_fdt0: 1 slot(s) allocated mmc1: on sdhci_fdt0 ehci0: mem 0xfe380000-0xfe39ffff irq 13 on = ofwbus0 usbus0: EHCI version 1.0 usbus0 on ehci0 ohci0: mem 0xfe3a0000-0xfe3bffff irq 14 on = ofwbus0 usbus1 on ohci0 ehci1: mem 0xfe3c0000-0xfe3dffff irq 15 on = ofwbus0 usbus2: EHCI version 1.0 usbus2 on ehci1 ohci1: mem 0xfe3e0000-0xfe3fffff irq 16 on = ofwbus0 usbus3 on ohci1 rk_dwc30: on ofwbus0 xhci0: mem 0xfe800000-0xfe8fffff irq 83 on = rk_dwc30 xhci0: 64 bytes context size, 32-bit DMA usbus4: trying to attach usbus4 on xhci0 rk_dwc31: on ofwbus0 xhci1: mem 0xfe900000-0xfe9fffff irq 84 on = rk_dwc31 xhci1: 64 bytes context size, 32-bit DMA usbus5: trying to attach usbus5 on xhci1 iicbus0: at addr 0x22 iic0: on iicbus0 iic1: on iicbus1 uart0: <16750 or compatible> mem 0xff180000-0xff1800ff irq 26 on ofwbus0 uart1: <16750 or compatible> mem 0xff1a0000-0xff1a00ff irq 28 on ofwbus0 uart1: console (1500000,n,8,1) spi0: mem 0xff1d0000-0xff1d0fff irq 31 on ofwbus0 spibus0: on spi0 mx25l0: at cs 0 mode 0 on spibus0 mx25l0: device type gd25q128, size 16384K in 256 sectors of 64K, erase = size 4K iicbus2: at addr 0x82 iic2: on iicbus2 iicbus3: at addr 0x44 iic3: on iicbus3 pwm0: mem 0xff420000-0xff42000f on ofwbus0 pwmbus0: on pwm0 pwmc0: channel 0 on pwmbus0 pwm1: mem 0xff420020-0xff42002f on ofwbus0 pwmbus1: on pwm1 pwmc1: channel 0 on pwmbus1 gpioc0: on gpio0 gpioc1: on gpio1 gpioc2: on gpio2 gpioc3: on gpio3 gpioc4: on gpio4 gpioled0: on ofwbus0 cryptosoft0: Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 ugen1.1: at usbus1 ugen0.1: at usbus0 uhub0 on usbus0 uhub0: on = usbus0 uhub1 on usbus1 uhub1: on = usbus1 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 ugen2.1: at usbus2 uhub2 on usbus2 uhub2: on = usbus2 ugen3.1: at usbus3 uhub3 on usbus3 uhub3: on = usbus3 usbus4: 5.0Gbps Super Speed USB v3.0 usbus5: 5.0Gbps Super Speed USB v3.0 uhub1: 1 port with 1 removable, self powered ugen4.1: at usbus4 uhub4 on usbus4 uhub4: on = usbus4 ugen5.1: at usbus5 uhub5 on usbus5 uhub5: on = usbus5 uhub3: 1 port with 1 removable, self powered nvd0: NVMe namespace nvd0: 488386MB (1000215216 512 byte sectors) mmcsd0: 16GB at mmc0 = 50.0MHz/4bit/2048-block mmc1: No compatible cards found on bus Release APs...done CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> Trying to mount root from ufs:/dev/mmcsd0p2 [rw,noatime]... Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <> Processor Features 0 =3D Processor Features 1 =3D <> Memory Model Features 0 =3D Memory Model Features 1 =3D <8bit VMID> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 = Breakpoints,PMUv3,Debugv8> Debug Features 1 =3D <> Auxiliary Features 0 =3D <> Auxiliary Features 1 =3D <> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 Unresolved linked clock found: clkin_gmac uhub4: 2 ports with 2 removable, self powered uhub0: 1 port with 1 removable, self powered mmc0: CMD7 failed, RESULT: 1 mmc0: Card at relative address 7 failed to select mmcsd0: Error indicated: 1 Timeout Fatal data abort: x0: ffffa00000cf9b00 x1: ffff000063dc9000 x2: 40 x3: ffff000040de1100 x4: ffff00005a1abaa0 x5: ffff00005a1ab7a0 x6: 0 x7: 6a0 x8: 0 x9: ffff0000006d2df0 x10: 2 x11: 0 x12: 1 x13: 2af8 x14: 43f x15: 2 x16: ffffffff x17: 3 x18: ffff00005a1ab860 x19: ffffa00000cf7c00 x20: 80 x21: ffff0000006f1000 x22: ffff0000006f1000 x23: ffff000064b43788 x24: 0 x25: ffffa00000cf5b80 x26: ffffa00000c2a3b4 x27: ffffa00000cf9e00 x28: ffffa00000cf5b80 x29: ffff00005a1ab860 sp: ffff00005a1ab860 lr: ffff0000004edfe8 elr: ffff0000004ee048 spsr: 145 far: 18 esr: 96000004 panic: vm_fault failed: ffff0000004ee048 cpuid =3D 3 time =3D 2 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x30 pc =3D 0xffff0000004c79f0 lr =3D 0xffff00000002f360 sp =3D 0xffff00005a1ab280 fp =3D 0xffff00005a1ab480 db_trace_self_wrapper() at vpanic+0x194 pc =3D 0xffff00000002f360 lr =3D 0xffff0000002185a0 sp =3D 0xffff00005a1ab490 fp =3D 0xffff00005a1ab4f0 vpanic() at panic+0x44 pc =3D 0xffff0000002185a0 lr =3D 0xffff000000218408 sp =3D 0xffff00005a1ab500 fp =3D 0xffff00005a1ab5b0 panic() at data_abort+0x1d8 pc =3D 0xffff000000218408 lr =3D 0xffff0000004e89e0 sp =3D 0xffff00005a1ab5c0 fp =3D 0xffff00005a1ab630 data_abort() at do_el1h_sync+0x144 pc =3D 0xffff0000004e89e0 lr =3D 0xffff0000004e7acc sp =3D 0xffff00005a1ab640 fp =3D 0xffff00005a1ab680 do_el1h_sync() at handle_el1h_sync+0x78 pc =3D 0xffff0000004e7acc lr =3D 0xffff0000004ca078 sp =3D 0xffff00005a1ab690 fp =3D 0xffff00005a1ab7d0 handle_el1h_sync() at dwmmc_intr+0x94 pc =3D 0xffff0000004ca078 lr =3D 0xffff0000004edfe4 sp =3D 0xffff00005a1ab7e0 fp =3D 0xffff00005a1ab860 dwmmc_intr() at ithread_loop+0x418 pc =3D 0xffff0000004edfe4 lr =3D 0xffff0000001d67e8 sp =3D 0xffff00005a1ab870 fp =3D 0xffff00005a1ab8f0 ithread_loop() at fork_exit+0x90 pc =3D 0xffff0000001d67e8 lr =3D 0xffff0000001d1ecc sp =3D 0xffff00005a1ab900 fp =3D 0xffff00005a1ab950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff0000001d1ecc lr =3D 0xffff0000004e7818 sp =3D 0xffff00005a1ab960 fp =3D 0x0000000000000000 KDB: enter: panic [ thread pid 11 tid 100043 ] Stopped at dwmmc_intr+0xf8: ldr w8, [x8, #24] db>=20 -- S=C3=B8ren Schmidt sos@deepcore.dk / sos@freebsd.org = "So much code to hack, so little time=E2=80=9D From owner-freebsd-arm@freebsd.org Thu Dec 31 13:08:28 2020 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 B03954C178B for ; Thu, 31 Dec 2020 13:08:28 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D67kh3GgCz4ldN for ; Thu, 31 Dec 2020 13:08:28 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.94 (FreeBSD)) (envelope-from ) id 1kuxgg-000BMS-1D for freebsd-arm@freebsd.org; Thu, 31 Dec 2020 14:08:18 +0100 Date: Thu, 31 Dec 2020 14:08:18 +0100 From: Kurt Jaeger To: freebsd-arm@freebsd.org Subject: poudriere builds (base: amd64, jail: arm64.aarch64) and resource limits Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4D67kh3GgCz4ldN X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE]; local_wl_from(0.00)[freebsd.org] 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, 31 Dec 2020 13:08:28 -0000 Hello, Roland posted a patch to build databases/cassandra4 on arm64.aarch64 in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252068 and I built it on my 13-jail: arm 13.0-CURRENT 1300132 r368817 arm64.aarch64 svn+ssh 2020-12-20 10:38:52 /pou/jails/arm The build fails almost at the end with: cd /wrkdirs/usr/ports/databases/cassandra4/work/apache-cassandra-4.0-beta2-src/build/dist && /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) && /usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE javadoc /wrkdirs/usr/ports/databases/cassandra4/work/stage/usr/local/share/doc/cassandra/ find: /bin/sh: Argument list too long *** Error code 1 and Ronald compared it to a build on amd64. He found that my jail has a surprising small data seg size: data seg size (kbytes, -d) 131072 Any ideas on how to raise the data seg size in the poudriere jail ? -- pi@opsec.eu +49 171 3101372 Now what ? From owner-freebsd-arm@freebsd.org Thu Dec 31 13:18:31 2020 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 6B1164C1B8F for ; Thu, 31 Dec 2020 13:18:31 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D67yG09GCz4ljY for ; Thu, 31 Dec 2020 13:18:29 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1609420702; 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=fRSGkPFyY6Ub1vkS3uA6LTaAMb6E2l5BVJyDO7GTyVs=; b=cJC7/ZNXjg2YgAkFk/PCCys76IX0Z6XzYWYAADfhUVEjR/b3aWbkKtq4Go1QLBpNi9NamY LC4cweg4qTua+pvj8YNNS/kfpZvkw33BNOpkU61W2bT3BjU5uyEHS5i4mR7swn7sT5Dq4V FqP6IRvWGpAU5koNnYmPdDbQmRhsQgU= Received: from amy (31-38-167-109.abo.bbox.fr [31.38.167.109]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 286c8c8a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 31 Dec 2020 13:18:21 +0000 (UTC) Date: Thu, 31 Dec 2020 14:18:21 +0100 From: Emmanuel Vadot To: =?ISO-8859-1?Q?S=F8ren?= Schmidt Cc: freebsd-arm Subject: Re: FreeBSD-13.0-CURRENT-arm64-aarch64-ROCKPRO64-20201210-7578a4862f0 broken ? Message-Id: <20201231141821.274a45ffa0299cca5a7bb1f1@bidouilliste.com> In-Reply-To: References: <4434862ed87c21113fb7f98636fe4694d73856ce.camel@freebsd.org> <0D6FCA87-F101-4AA0-A1BF-6EDBA003BC9F@gmail.com> <87B7940E-119D-4C7F-AB9D-0C78E7F8D3A3@gmail.com> <20201213180746.1224166dffb81cb6770ff80d@bidouilliste.com> <6784D541-8FED-4753-8631-B36886508165@gmail.com> <23CCE944-C9F0-42C9-8A93-DAC312FE01E2@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4D67yG09GCz4ljY X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=cJC7/ZNX; 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 [-0.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_ALL(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]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; 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]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[212.83.155.74:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; 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: Thu, 31 Dec 2020 13:18:31 -0000 On Thu, 31 Dec 2020 13:49:19 +0100 S=F8ren Schmidt wrote: > Hi gang >=20 > On my quest on getting the pinebookpro booting again I think I can rule o= ut u-boot for now. I thought it was rockpro64 that gave you problems ? > Back on the u-boot-2020.07 where a -current kernel from late July/early a= ugust would boot just fine a current kernel fails to talk to the SD card, t= he only change to an up to date current is not setting the 800Hmz cpll cloc= k and that is known not to make any difference. How is it known that it doesn't make any difference ? cpll is one of the possible parent (and likely the default one) for sd/emmc/sdio clocks. Did you tested without this change ? > Again the same SDcard works just dandy with net/openBSD also I 50Mhz mode= . 1 in 10 boots finds the card as 25Mhz and then it ?just works?. >=20 > Any Ideas ? Cna you provide a boot verbose log please ? > U-Boot TPL 2020.07 (Aug 09 2020 - 14:11:44) > Channel 0: LPDDR4, 50MHz > BW=3D32 Col=3D10 Bk=3D8 CS0 Row=3D15 CS1 Row=3D15 CS=3D2 Die BW=3D16 Size= =3D2048MB > Channel 1: LPDDR4, 50MHz > BW=3D32 Col=3D10 Bk=3D8 CS0 Row=3D15 CS1 Row=3D15 CS=3D2 Die BW=3D16 Size= =3D2048MB > 256B stride > 256B stride > lpddr4_set_rate: change freq to 400000000 mhz 0, 1 > lpddr4_set_rate: change freq to 800000000 mhz 1, 0 > Trying to boot from BOOTROM > Returning to boot ROM... >=20 > U-Boot SPL 2020.07 (Aug 09 2020 - 14:11:44 +0200) > Trying to boot from MMC1 >=20 >=20 > U-Boot 2020.07 (Aug 09 2020 - 14:11:44 +0200) >=20 > SoC: Rockchip rk3399 > Reset cause: POR > Model: Pine64 Pinebook Pro > DRAM: 3.9 GiB > PMIC: RK808=20 > MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0 > Loading Environment from SPI Flash... SF: Detected gd25q128 with page siz= e 256 Bytes, erase size 4 KiB, total 16 MiB > OK > In: serial > Out: vidconsole > Err: vidconsole > Model: Pine64 Pinebook Pro > Net: No ethernet found. > Card did not respond to voltage select! > Hit any key to stop autoboot: 0=20 > switch to partitions #0, OK > mmc1 is current device > Scanning mmc 1:1... > 80449 bytes read in 16 ms (4.8 MiB/s) > Found EFI removable media binary efi/boot/bootaa64.efi > Card did not respond to voltage select! > Scanning disk mmc@fe310000.blk... > Disk mmc@fe310000.blk not ready > Scanning disk mmc@fe320000.blk... > ** Unrecognized filesystem type ** > Card did not respond to voltage select! > Scanning disk sdhci@fe330000.blk... > Disk sdhci@fe330000.blk not ready > Found 3 disks > BootOrder not defined > EFI boot manager: Cannot load any image > 1091484 bytes read in 123 ms (8.5 MiB/s) >=20 > Consoles: EFI console =20 > Reading loader env vars from /efi/freebsd/loader.env > Setting currdev to disk0p1: > FreeBSD/arm64 EFI loader, Revision 1.1 > (Thu Dec 31 13:17:08 CET 2020 sos@newport.deepcore.dk) >=20 > Command line arguments: loader.efi > Image base: 0xf3dfe000 > EFI version: 2.80 > EFI Firmware: Das U-Boot (rev 8224.1792) > Console: comconsole (0) > Load Path: /efi\boot\bootaa64.efi > Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/= HD(1,GPT,319e202c-4b62-11eb-bf03-0800274503a7,0x8000,0x10000) > Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1= ,GPT,319e202c-4b62-11eb-bf03-0800274503a7,0x8000,0x10000) > Setting currdev to disk0p1: > Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,GPT= ,319e202c-4b62-11eb-bf03-0800274503a7,0x18000,0x1e7fd8) > Setting currdev to disk0p2: > Loading /boot/defaults/loader.conf > Loading Kernel and Modules (Ctrl-C to Abort) > .................................................. > /boot/kernel/kernel text=3D0x2a8 text=3D0x512fd8 text=3D0x1467b4 data=3D0= x138930 data=3D0x0+0x52e000 syms=3D[0x8+0xb3730+0x8+0xbdce7] > | > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by EFI at 0x80e9000. > EFI framebuffer information: > addr, size 0xf7800000, 0x3f4800 > dimensions 1920 x 1080 > stride 1920 > masks 0x0000f800, 0x000007e0, 0x0000001f, 0x00000000 > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2020 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.0-CURRENT #6 main-c255441-g4e4e43dc9e1a-dirty: Thu Dec 31 13:1= 6:59 CET 2020 > sos@newport.deepcore.dk:/usr/home/sos/FreeBSD/embedded/aarch64-obj/us= r/home/sos/FreeBSD/git-current/arm64.aarch64/sys/PINEBOOKPRO arm64 > FreeBSD clang version 11.0.0 (git@github.com:llvm/llvm-project.git llvmor= g-11.0.0-0-g176249bd673) > VT(efifb): resolution 1920x1080 > real memory =3D 4158349312 (3965 MB) > avail memory =3D 4033499136 (3846 MB) > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > arc4random: WARNING: initial seeding bypassed the cryptographic random de= vice because it was not yet seeded and the knob 'bypass_before_seeding' was= enabled. > random: entropy device external interface > MAP f3f0f000 mode 2 pages 1 > MAP f3f12000 mode 2 pages 2 > MAP f6f30000 mode 2 pages 16 > WARNING: Device "openfirm" is Giant locked and may be deleted before Free= BSD 13.0. > WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 1= 3.0. > kbd0 at kbdmux0 > ofwbus0: > clk_fixed0: on ofwbus0 > simplebus0: on ofwbus0 > rk_grf0: mem 0xff320000-0xff320fff on o= fwbus0 > rk3399_pmucru0: mem 0xff750000= -0xff750fff on ofwbus0 > rk3399_cru0: mem 0xff760000-0xff76= 0fff on ofwbus0 > Cannot set frequency for clk: cpll, error: 22 > rk3399_cru0: Failed to set cpll to a frequency of 800000000 > rk_grf1: mem 0xff770000-0xff77ffff on o= fwbus0 > regfix0: on ofwbus0 > regfix1: on ofwbus0 > regfix2: on ofwbus0 > regfix3: on ofwbus0 > regfix4: on ofwbus0 > regfix5: on ofwbus0 > regfix6: on ofwbus0 > regfix7: on ofwbus0 > regfix8: on ofwbus0 > regfix9: on ofwbus0 > regfix10: on ofwbus0 > regfix11: on ofwbus0 > simple_mfd0: mem 0xff310000-0xff310= fff on ofwbus0 > psci0: on ofwbus0 > gic0: mem 0xfee00000-0xfee0ffff,0= xfef00000-0xfefbffff,0xfff00000-0xfff0ffff,0xfff10000-0xfff1ffff,0xfff20000= -0xfff2ffff irq 18 on ofwbus0 > its0: mem 0xfee20000-0xfee3ffff o= n gic0 > rk_iodomain0: mem 0xff320000-0xff320fff on r= k_grf0 > rk_iodomain1: mem 0-0xff76ffff,0-0xffff on r= k_grf1 > rk_pinctrl0: on ofwbus0 > gpio0: mem 0xff720000-0xff7200ff irq 71 o= n rk_pinctrl0 > gpiobus0: on gpio0 > gpio1: mem 0xff730000-0xff7300ff irq 72 o= n rk_pinctrl0 > gpiobus1: on gpio1 > gpio2: mem 0xff780000-0xff7800ff irq 73 o= n rk_pinctrl0 > gpiobus2: on gpio2 > gpio3: mem 0xff788000-0xff7880ff irq 74 o= n rk_pinctrl0 > gpiobus3: on gpio3 > gpio4: mem 0xff790000-0xff7900ff irq 75 o= n rk_pinctrl0 > gpiobus4: on gpio4 > rk_i2c0: mem 0xff110000-0xff110fff irq 20 on ofwbus0 > iicbus0: on rk_i2c0 > rk_i2c1: mem 0xff130000-0xff130fff irq 22 on ofwbus0 > iicbus1: on rk_i2c1 > rk_i2c2: mem 0xff3c0000-0xff3c0fff irq 38 on ofwbus0 > iicbus2: on rk_i2c2 > syr8270: at addr 0x80 on iicbus2 > rk_i2c3: mem 0xff3d0000-0xff3d0fff irq 39 on ofwbus0 > iicbus3: on rk_i2c3 > rk805_pmu0: at addr 0x36 irq 76 on iicbus2 > generic_timer0: irq 2,3,4,5 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > rk_tsadc0: mem 0xff260000-0xff2600ff irq 3= 5 on ofwbus0 > rk_usb2phy0: mem 0-0xff76ffff,0-0xffff on rk_gr= f1 > rk_usb2phy1: mem 0-0xff76ffff,0-0xffff on rk_gr= f1 > rk_emmcphy0: mem 0-0xff76ffff,0-0xffff on rk_g= rf1 > rk_pcie_phy0: mem 0-0xff76ffff,0-0xffff on rk_= grf1 > rk_typec_phy0: mem 0xff7c0000-0xff7fffff on o= fwbus0 > rk_typec_phy1: mem 0xff800000-0xff83ffff on o= fwbus0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpufreq_dt0: on cpu0 > cpu1: on cpulist0 > cpufreq_dt1: on cpu1 > cpu2: on cpulist0 > cpufreq_dt2: on cpu2 > cpu3: on cpulist0 > cpufreq_dt3: on cpu3 > cpu4: on cpulist0 > cpufreq_dt4: on cpu4 > cpufreq_dt4: Not attaching as cpu is not present > device_attach: cpufreq_dt4 attach returned 6 > cpu5: on cpulist0 > cpufreq_dt5: on cpu5 > cpufreq_dt5: Not attaching as cpu is not present > device_attach: cpufreq_dt5 attach returned 6 > pmu0: irq 0 on ofwbus0 > pmu1: irq 1 on ofwbus0 > pcib0: mem 0xf8000000-0xf9ffffff,0xfd000000-0x= fdffffff irq 6,7,8 on ofwbus0 > pci0: on pcib0 > pcib1: at device 0.0 on pci0 > pcib0: failed to reserve resource for pcib1 > pcib1: failed to allocate initial memory window: 0-0xfffff > pci1: on pcib1 > nvme0: at device 0.0 on pci1 > rockchip_dwmmc0: mem 0xfe310000-0xfe313fff irq 10 on ofwbus0 > rockchip_dwmmc0: Hardware version ID is 270a > rockchip_dwmmc1: mem 0xfe320000-0xfe323fff irq 11 on ofwbus0 > rockchip_dwmmc1: Hardware version ID is 270a > mmc0: on rockchip_dwmmc1 > sdhci_fdt0: mem 0xfe330000-0xfe33f= fff irq 12 on ofwbus0 > rk_emmcphy0: got emmcclk clock > sdhci_fdt0-slot0: Hardware doesn't specify timeout clock frequency, setti= ng BROKEN_TIMEOUT quirk. > sdhci_fdt0: 1 slot(s) allocated > mmc1: on sdhci_fdt0 > ehci0: mem 0xfe380000-0xfe39ffff irq 13 on ofwb= us0 > usbus0: EHCI version 1.0 > usbus0 on ehci0 > ohci0: mem 0xfe3a0000-0xfe3bffff irq 14 on ofwb= us0 > usbus1 on ohci0 > ehci1: mem 0xfe3c0000-0xfe3dffff irq 15 on ofwb= us0 > usbus2: EHCI version 1.0 > usbus2 on ehci1 > ohci1: mem 0xfe3e0000-0xfe3fffff irq 16 on ofwb= us0 > usbus3 on ohci1 > rk_dwc30: on ofwbus0 > xhci0: mem 0xfe800000-0xfe8fffff irq 83 on rk_= dwc30 > xhci0: 64 bytes context size, 32-bit DMA > usbus4: trying to attach > usbus4 on xhci0 > rk_dwc31: on ofwbus0 > xhci1: mem 0xfe900000-0xfe9fffff irq 84 on rk_= dwc31 > xhci1: 64 bytes context size, 32-bit DMA > usbus5: trying to attach > usbus5 on xhci1 > iicbus0: at addr 0x22 > iic0: on iicbus0 > iic1: on iicbus1 > uart0: <16750 or compatible> mem 0xff180000-0xff1800ff irq 26 on ofwbus0 > uart1: <16750 or compatible> mem 0xff1a0000-0xff1a00ff irq 28 on ofwbus0 > uart1: console (1500000,n,8,1) > spi0: mem 0xff1d0000-0xff1d0fff irq 31 on ofwbus0 > spibus0: on spi0 > mx25l0: at cs 0 mode 0 on spibus0 > mx25l0: device type gd25q128, size 16384K in 256 sectors of 64K, erase si= ze 4K > iicbus2: at addr 0x82 > iic2: on iicbus2 > iicbus3: at addr 0x44 > iic3: on iicbus3 > pwm0: mem 0xff420000-0xff42000f on ofwbus0 > pwmbus0: on pwm0 > pwmc0: channel 0 on pwmbus0 > pwm1: mem 0xff420020-0xff42002f on ofwbus0 > pwmbus1: on pwm1 > pwmc1: channel 0 on pwmbus1 > gpioc0: on gpio0 > gpioc1: on gpio1 > gpioc2: on gpio2 > gpioc3: on gpio3 > gpioc4: on gpio4 > gpioled0: on ofwbus0 > cryptosoft0: > Timecounters tick every 1.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 12Mbps Full Speed USB v1.0 > ugen1.1: at usbus1 > ugen0.1: at usbus0 > uhub0 on usbus0 > uhub0: on usbus0 > uhub1 on usbus1 > uhub1: on usbus1 > usbus2: 480Mbps High Speed USB v2.0 > usbus3: 12Mbps Full Speed USB v1.0 > ugen2.1: at usbus2 > uhub2 on usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3 on usbus3 > uhub3: on usbus3 > usbus4: 5.0Gbps Super Speed USB v3.0 > usbus5: 5.0Gbps Super Speed USB v3.0 > uhub1: 1 port with 1 removable, self powered > ugen4.1: at usbus4 > uhub4 on usbus4 > uhub4: on usbu= s4 > ugen5.1: at usbus5 > uhub5 on usbus5 > uhub5: on usbu= s5 > uhub3: 1 port with 1 removable, self powered > nvd0: NVMe namespace > nvd0: 488386MB (1000215216 512 byte sectors) > mmcsd0: 16GB at mmc0 50= .0MHz/4bit/2048-block > mmc1: No compatible cards found on bus > Release APs...done > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > Cache Type =3D <64 byte D-cacheline,64 byte I-cachelin= e,VIPT ICache,64 byte ERG,64 byte CWG> > Trying to mount root from ufs:/dev/mmcsd0p2 [rw,noatime]... > Instruction Set Attributes 0 =3D > Instruction Set Attributes 1 =3D <> > Processor Features 0 =3D > Processor Features 1 =3D <> > Memory Model Features 0 =3D > Memory Model Features 1 =3D <8bit VMID> > Memory Model Features 2 =3D <32bit CCIDX,48bit VA> > Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 Breakpoint= s,PMUv3,Debugv8> > Debug Features 1 =3D <> > Auxiliary Features 0 =3D <> > Auxiliary Features 1 =3D <> > CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > CPU 2: ARM Cortex-A53 r0p4 affinity: 2 > CPU 3: ARM Cortex-A53 r0p4 affinity: 3 > Unresolved linked clock found: clkin_gmac > uhub4: 2 ports with 2 removable, self powered > uhub0: 1 port with 1 removable, self powered > mmc0: CMD7 failed, RESULT: 1 > mmc0: Card at relative address 7 failed to select > mmcsd0: Error indicated: 1 Timeout > Fatal data abort: > x0: ffffa00000cf9b00 > x1: ffff000063dc9000 > x2: 40 > x3: ffff000040de1100 > x4: ffff00005a1abaa0 > x5: ffff00005a1ab7a0 > x6: 0 > x7: 6a0 > x8: 0 > x9: ffff0000006d2df0 > x10: 2 > x11: 0 > x12: 1 > x13: 2af8 > x14: 43f > x15: 2 > x16: ffffffff > x17: 3 > x18: ffff00005a1ab860 > x19: ffffa00000cf7c00 > x20: 80 > x21: ffff0000006f1000 > x22: ffff0000006f1000 > x23: ffff000064b43788 > x24: 0 > x25: ffffa00000cf5b80 > x26: ffffa00000c2a3b4 > x27: ffffa00000cf9e00 > x28: ffffa00000cf5b80 > x29: ffff00005a1ab860 > sp: ffff00005a1ab860 > lr: ffff0000004edfe8 > elr: ffff0000004ee048 > spsr: 145 > far: 18 > esr: 96000004 > panic: vm_fault failed: ffff0000004ee048 > cpuid =3D 3 > time =3D 2 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x30 > pc =3D 0xffff0000004c79f0 lr =3D 0xffff00000002f360 > sp =3D 0xffff00005a1ab280 fp =3D 0xffff00005a1ab480 >=20 > db_trace_self_wrapper() at vpanic+0x194 > pc =3D 0xffff00000002f360 lr =3D 0xffff0000002185a0 > sp =3D 0xffff00005a1ab490 fp =3D 0xffff00005a1ab4f0 >=20 > vpanic() at panic+0x44 > pc =3D 0xffff0000002185a0 lr =3D 0xffff000000218408 > sp =3D 0xffff00005a1ab500 fp =3D 0xffff00005a1ab5b0 >=20 > panic() at data_abort+0x1d8 > pc =3D 0xffff000000218408 lr =3D 0xffff0000004e89e0 > sp =3D 0xffff00005a1ab5c0 fp =3D 0xffff00005a1ab630 >=20 > data_abort() at do_el1h_sync+0x144 > pc =3D 0xffff0000004e89e0 lr =3D 0xffff0000004e7acc > sp =3D 0xffff00005a1ab640 fp =3D 0xffff00005a1ab680 >=20 > do_el1h_sync() at handle_el1h_sync+0x78 > pc =3D 0xffff0000004e7acc lr =3D 0xffff0000004ca078 > sp =3D 0xffff00005a1ab690 fp =3D 0xffff00005a1ab7d0 >=20 > handle_el1h_sync() at dwmmc_intr+0x94 > pc =3D 0xffff0000004ca078 lr =3D 0xffff0000004edfe4 > sp =3D 0xffff00005a1ab7e0 fp =3D 0xffff00005a1ab860 >=20 > dwmmc_intr() at ithread_loop+0x418 > pc =3D 0xffff0000004edfe4 lr =3D 0xffff0000001d67e8 > sp =3D 0xffff00005a1ab870 fp =3D 0xffff00005a1ab8f0 >=20 > ithread_loop() at fork_exit+0x90 > pc =3D 0xffff0000001d67e8 lr =3D 0xffff0000001d1ecc > sp =3D 0xffff00005a1ab900 fp =3D 0xffff00005a1ab950 >=20 > fork_exit() at fork_trampoline+0x10 > pc =3D 0xffff0000001d1ecc lr =3D 0xffff0000004e7818 > sp =3D 0xffff00005a1ab960 fp =3D 0x0000000000000000 >=20 > KDB: enter: panic > [ thread pid 11 tid 100043 ] > Stopped at dwmmc_intr+0xf8: ldr w8, [x8, #24] > db>=20 >=20 > -- > S=F8ren Schmidt > sos@deepcore.dk / sos@freebsd.org > "So much code to hack, so little time? >=20 >=20 >=20 >=20 > _______________________________________________ > 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" --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Dec 31 22:17:46 2020 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 D95DE4D1AB1 for ; Thu, 31 Dec 2020 22:17:46 +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 4D6MwT5KN5z3wTx for ; Thu, 31 Dec 2020 22:17: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=1609453064; bh=+eyCJO2eEsYYSAHnentq4+b8h0CFGj6mzBvDMDLc3JV=; h=Subject:From:Date:To:From:Subject; b=ZKtfz4haMPqMuyTJd7D6DsHVaW8FH5o7+VMGtXlpPEThDG5XHvRk9NS8VerurzDJbbI0J9LK23+vspM2XuJhlXVmTG3APJdWE2DCeKOXeL/znFQ9UxTZRHDmMHStgs25dmVRAb39FJydrOLjyh0TD63IxER3bE8mvsp3f0WgcaTpNLXSX5mCIh82+3dfajyAdQhnFeLRc3cFckgHDx8E7jNdidtaugL9Am02XqXW8YIfT6xv3edDMGxXT/0kDL78ICFVp9SeLeuCprPpoGDV9+0J6+/v2z/EC/pBhxqYF/c1TKn2c22oAFE1YHgH5P0fx7YKzk80u5di3agOjU5YdQ== X-YMail-OSG: YvAqz40VM1mPBW16PDFoP4E5iXoCjYD70YERnlVPTR5dZJB.CfSDnX7Je72Q0EI LkOensTQhvJ0gqgEKkyz3a2yAGjUYuV5y2QzxeCCf.IuJd7x2PRKpXPyFt9K4iqDDgQbaiSEJLxM iGqXfLFNu.7nUau777cfjxvCW70KCDcYXJjxKHvKNOs0dAsT_WgUoEhghHwCWRUQmtumGgI.TjE2 65aiGlxHyf890JdgBpdRfVFR3ua8jnVymbyIr5vcBgim6SfKSVyp.OplXWEqY3F.wdC4.0_YmQkN ZrznyBwyi.Qx1fYpBORYrdb1YWiJMaf.6uRWRDICjOC99vZY_pLhoI2MutWBEiZ6IPpqX9tVaKUN GVT1.D3Nhe.b5PRBzwLERr9._HuJUWi7xgBMhkwIzvOUqDMc1ONp338UrDue7pOU7G1ghNm7bCGd z3ayjnNs_HalGafVQz8Kx7nnbOZ3PABX65q22krMoYfojsZBgrbrZAjvpSwTVX9zq6JvCspTtsEt g_oLD6JnK2IyfIx35RnyE9xhyYQmY8_iI6Bexng9v8c0SMnUBsLwu0AlZl.x6hWhzFMFazxG5K.H .Qye.ZrZTM4LEGLwJGjmE5c6aFauX_p6eWyJT6wSI8gkfpNs54eK0IqLvCR6FQG_ywptLvjF8gPr SAkNS0ub1zbr3jdwmJdnpGrTAUeoW24mt1gPUxzQuj2ovOS6I5y6iKKRCjLL.7UxOnLyKQ9Po6Fa bmXhR2EH6nPry80joFNXS5iMP29fUWGX_7McM_Zh2TRS5_Kv2ShdUKT12vT097DlFlmeO_suW4u. GAuNx_sA6X6m1irJ6.LzzAyDcBTQ204NND1xjn9xIPu4akaPemixKWHtC8VVAEYRUCZxfhJ4ymB9 TXw65LObLzMp5JluOq073s7jnXNpN6z69ZgYRaRaj.zvwOPBnjME8WMPxiA3amniDUQ7Tb2UE4EG C7JaIsO6tCm5bbz8i5WMq7QxSxR1Wx_O6gTIm072mEFzBZh0cAqap82hXrORZLILtvHw.5s6W7Sa 0HIsp5.vVRwk1a4p0JNuwQqERWvU4vQ62fdzAaWcJEM6zC7CrLtSRpufk.Dljwwlo4xieCmA4ehJ 3h1ocUhKb1qggOdiPInlO9vmj1K9boKy.p6NilN9tlanqi0Yqr4Is0w8iYQ38WSCVa3.JU11Btvc cFXyPkJMJ1DEkLcmredPlHKNXMCoypD_sso0JMuTzg6p.a887_R2qED3frDrFnyKGwuKZPj.kxbe CmYKV8JNQBNV1X.AXIg3fK6qvpCVN1sCuj2Crm0uydeYdX0j4.2U8K2_WxSvzyBkFRN2aaKB2jdr st7mf1RddgigQi7fkzTYepPTNQtxNlvo6tsIwFXXF_3QO_2n7GLvmCAltOnVLFDPwbBTaFUcRQxs Ar.U2coykxuRex1vLlw1MYF9tX2V2AhmN1IkI95cMKlCPF8v_soPcd.2cB2jezxuskFH6F1wQDaV WaDsVTwNM9eNvBcSpXwNoMGNvdMnr4mcTt__OniA8L2kiYkJ5O4jjzdUFb5EhZAo6R82i9.deZTm iAn7_aw1_cz6u2Dyf2RFw_ynQwRqIncej8TG50OzoUtLg6rtFDbc2KMUli6JtbSzFy9GU7mKIvWm DU2xRvqj5pNL4Wrvw6B0XGr54cYSdE5pJgqPECXcoTPxAxTt3kEACMFW_pCEqoHnpuJnAtUXNvkw feAintJb548QTzjuiiezp7XQuGahLAUbqLtcXTpopdgHHHIs7t3V8YSw7on9U5SlmcsBQ9FAyViY XTzbTLF2XxZ8IBgUl38mU2pyloOiZ_loWdsAOdxv6O6uFxCChvPBHaNgrgd.WBLUW73XC6ZYeItZ m4UFKoi4CX4bxFft0_mtc0c1JZ0GLXubpXY8hWWWDwh4_fbIbLcsk_liTZgLZrJZeM5ih3CBEKqL AMZOQoWbE6Hz66VkSNRzhtju9X0NJpmNvk1Rtc1CQgzrcR1ARn4y4ZLOhN1B0Umx7..ML31eSprw q4WLCCjVC9ostM8Rt6AljMnI2qm6YGjoDMI8TZB_lo5WGHwp07QZXpL4Lj8Ef5Em9LuVGB4fwRFC 8T._eQj5OOkkTFFXpfe3qhLO6iu1xWsA92_07.HRB0WPZ_FY1cZwLNgaqR2Ue4xWYopirymuyoI6 0Gb2FwFPWzEe5JVXFU5BwdlkaNNz4PmS6Wg7S4PfcniEXbQMVDepiaq5kjPUo30lLvndGKIJVGJb ZLOGSG10pB6fWbd2tZKKcI8pJFWUnns1TXu4xyTsq9uDDyClKwgtR8ejTdFN9Gwm8N28mYl7xw2u TmzYkrdXx2FgFpCy7VO6kvKiOpRE9wjOqM2qzDMNztp_AozN.lgTBeHHTr5YADHO4vLWyNTriTUi ECxjEB1p2GwBKSr4pkkUWTKo.8tB.fzzQg4cCLlkZhbVKEqlYjAcDhlR.k.CGS93rnab4j7qlApk jewefkarojq_fD_vfseGSl5nSSfvUYohiq.AQ8Inrqw_kxT8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 31 Dec 2020 22:17:44 +0000 Received: by smtp410.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6608a4f25feee85642237be2b3fffff2; Thu, 31 Dec 2020 22:17:40 +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: poudriere builds (base: amd64, jail: arm64.aarch64) and resource limits From: Mark Millard In-Reply-To: Date: Thu, 31 Dec 2020 14:17:38 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3A095111-BE41-424A-AC51-DC848040C6B7@yahoo.com> References: To: Kurt Jaeger X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D6MwT5KN5z3wTx X-Spamd-Bar: - X-Spamd-Result: default: False [-1.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]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; 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: Thu, 31 Dec 2020 22:17:46 -0000 On 2020-Dec-31, at 05:08, Kurt Jaeger wrote: > Hello, >=20 > Roland posted a patch to build databases/cassandra4 on arm64.aarch64 = in > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252068 > and I built it on my 13-jail: >=20 > arm 13.0-CURRENT 1300132 r368817 arm64.aarch64 svn+ssh 2020-12-20 = 10:38:52 /pou/jails/arm >=20 > The build fails almost at the end with: >=20 > cd = /wrkdirs/usr/ports/databases/cassandra4/work/apache-cassandra-4.0-beta2-sr= c/build/dist && /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio = -dumpl $2 >/dev/null 2>&1) && /usr/bin/find -Ed $1 $3 \( -type d = -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} + -o = -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + = \)' COPYTREE_SHARE javadoc = /wrkdirs/usr/ports/databases/cassandra4/work/stage/usr/local/share/doc/cas= sandra/ > find: /bin/sh: Argument list too long > *** Error code 1 >=20 > and Ronald compared it to a build on amd64. He found that my jail has > a surprising small data seg size: >=20 > data seg size (kbytes, -d) 131072 >=20 > Any ideas on how to raise the data seg size in the poudriere jail ? >=20 What does rctl report? (Not that I've ever used RACCT/RCTL.) # rctl rctl: RACCT/RCTL present, but disabled; enable using kern.racct.enable=3D1= tunable =46rom what I read in man rctl, "jail" is one of the "subject" = categories and "datasize" is one of the "resources". So it looks like rctl is one of = the ways a specific limit could be imposed. I'm guessing you would look/control from outside the jail. =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 1 03:25:24 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 57EC44BC2DA for ; Fri, 1 Jan 2021 03:25:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.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 4D6VlQ66xHz4qGF for ; Fri, 1 Jan 2021 03:25:22 +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=1609471521; bh=//fK60RJfWXqJkbeITsNF7lEjGoYAtwBcPVCvFf3UNh=; h=Subject:From:Date:To:From:Subject; b=X6cblnxC3SSbIiH56br5W28phKSyGDLTJmOP0sy3PPUsMxdmRUmYMkhryhV1T0VylLm9W4Hs8AGUzg/7+aJbl6gHdxH0TVX3KHkxwJ9zEIUqzj9kbFK0xPkNM08RvkRlhZCW+ATvruqy0GropM02J9kzj6Gbi1uOA6i2R+VhUGfnN0OZGqMVVGfFc21/nPHMrC3MgbumO9fUjCQZwGzr4NQtFqIO6IxHiXkrLsgvl3kxj78nqtavIYWu/ObERCqNmbIRTbh49GhpddLTJ+aXAGXSFxfxJD/PzuupU6diTfyCsfS5k1FL03zK5h3QMgJOmOd1nB3QdA+aJv0SD0G4PQ== X-YMail-OSG: QtN13dIVM1mRHOQ.rc_VB_JBLcrH3dmkREeS4LfLSveoce.NkkwWprj.XR1Uqpb 7ks.R.C8b3_4xN6AfeKeeOVoTpESosBqjdDVnUfsXSWArUu2oxRu9WW7xPoTY9xFxcfyG6wRHU09 ESKHvLVi_6461AMWhcXnNHnPBZXTX2KwZIJilwtd4yy12pEbWH.XhJZGpEEG5Q8yG5dsZrkVrA.F lkSjNoCpeve8POgrThOzrV.yVtfv.FdtOz0ng2zAHATnzQ50j0YCiDehIJKXQvAoK7D5GVXndZLx I5lAZqkTgQjCfu.gKkCUnlwZRuMFUyhOUrIsycXRP1ZRPW4XM6bSusS.w3Ltw1YAdaZ.y06viQQe XANpH1ShvHlefkGMn.gBUjiUb7gK6agdg3Hyto74d3hIjekKUqqtHzT4a06Ze9PUkcBqNRpSHywy UyD3u_7PXeczbpm2H2muGoYQAWqcwma53I8_wWsg4o2CNFrpMuQCslEeDDNErPxPUyJQlAU8dsm0 rDLz4T7M5AHpCiNtazAsejtPhuYQSfxBuQPiL92jpmsi39KgyiNHinWWmMhQwyQLZXBkIag6FO9Y .mqL9tkqbBW8EkJ3NgRdhILaHdU_ioLXtHOqg711VJRxH.Iv551eoJWNEIhX4iGcm4acGs8STG2q 4AzE2JHG5jz8KmVf_KRELTGYOkEjKElFuASdofPAQe3nJcrFprtjWfCX3qvkSemljiZ7BHfUaRAg _X.Sori4n6cxdtmWQb4bx27l2e3Eejak1xzlLZ4uqrUK9.UslwnG9IZ98h_0pZXtwS.IgavOKUvG _CP_o6FGXoH7yGlv2rOKPCO1YxhcRasQ_rIePywarvcspUTpFwumkqtV3LwPBeu9IYUJm.E9Ftn7 wzStuNdxKOGKGlHCmibpRuqCKvO0d6L1YB1zlYvVEEr4l1N8KdrjJREI3O5gV.NHOe.0f6VQSv5J uX85xZAW2xiUnGmOhe32ZhDzTwvtrKXb.qAy5UjyQiQoTpgkYEnrJkzyRzBxCHCmJG60Wv2jaxzY gRVNO0TCaGuBz6nNBwz1gzFy2nA4AUIDRgH99xr.TQsXBU4OgxvSRdy49gzO3rTbmoTgppgPYJ1Z 8Bvld7A00R2pnyp0s58jBv6_WTsmvfJZj.G_b32O9yZLjEJVGjaxZFeVpFkRHXZ.XT15Et5oey2B 33Kv192WjEbDFGCuOSqmcNt78E8UhUiwHFe533lcklKFz0VpGf9UG1A4mD58nxCfT68gbAJOfls2 jsIT4VfYvLJ1Ayn_SPGRPXjU8TRUXk7ez.X1Wdm4UMUlbnWtWd1JKz2QUOH2Zgsv37Ljg5FxWfdS f8rsPlyPpQ0ro0ll9lIQjaedY_OYGGa208fR2eW0is13IXI2Krqd1BzD_rxqT.wGFTAFBk6XR6Gi .22XIZQXZT91HFefKpl3OsuCT465bbyMODodKF1Lq40ZluywTsQkQwXQU5A6zprkSF.L.wiYlz97 ebwXO30tLZrG9NdJy5rfHVHTyCSCmIjO74qeIj9tKi7ahCwlJrPVfLE6h8hNoynoAxLOcO2fFiCH 7BHGPouexc.WvYX13B4qdOv4phJznbPn2G27KYR5EY5vtEhYme77ibXIGj8MzCP3R48PHNnh0jbj Sm9Z1tqTS3LcpIlhOxVmyykbdH9h5qETUFBXcHiNqiBIuRZLnpZAEIToWwmxhMM4RtEouvgc96nz t_j_.b_hmqaY9CserOGuo41B_vr85hKuWeVWiCZoX2GLu87emu2Kd3GJ_RfEonXM.HFhH9EFI00m 9wTYN07il5qdfl3yeuXc_FkPLb07KWcKxX3EuE2OWWo6ZrCzsv7cO54GIAsr4BG86VbpO.lHfrND njplTxOdxyNa4UA_VVUeCZu9YJ5G4MyYkgrghS7qFNJ3Au12Dhdg0sABtoT4nHdW9.YKD8sovRan Mq3XAvQw.YW6RfleRZDXhOtiCKag3E44pdftadjf9BsMlLnjJPMoj5DS5hVbf1VKldP90p2jyezQ qJwz7IM9H3Y2oQQEgIQoozO_DIV2sLAb68ARJtu4Q7olj2THCmW6nNMcgmI8ieRp5qLW9uHOydgk Uu4f6yiK0sVlkTSfka2bbcuq3ARy9AryhJqddr74pUKndjJyz9_4I0XUZ_dFK24_BIVUEhkWDIIu Wl39ieGe_4NAOSMdMdmoE.PQroFQczbSqep2zJYsd5HU_Wz5WSwxPqisi5H_pgjcJrzkNJvUXhZx xwwlbO4nAHXq_A3M4Lu6dvSxC_1ThV0eKeY4fytNNKfR22qhrnA1RrB4pNPsZ4hU7ZShuw2KYTtU 1kxdDFXvL8JdNjYUxHHRJGKOQB3X21fgGnnEggvc_mErgiEPD_QRE5cGttXvkAzZlDxcf2aTr8LI XjNGNfdDtCfn174CrBPoJr4GeQNFa3ynaBOiEB30sJYzEC1WuLqT1MI1ux3zcdni9QlnLCfufFA4 tyJ2BwC9kq_v8_RR56OLqELpEAPP2XsMZX8bovCguinaerxBSPDenGWWAiwBzsqIhecx.Eqb0UeQ T8p9zKpMbs49zWXwtHCQO Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 1 Jan 2021 03:25:21 +0000 Received: by smtp417.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6b4b1a373d546fe0cfc5f3d62c066072; Fri, 01 Jan 2021 03:25:18 +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: poudriere builds (base: amd64, jail: arm64.aarch64) and resource limits From: Mark Millard In-Reply-To: <3A095111-BE41-424A-AC51-DC848040C6B7@yahoo.com> Date: Thu, 31 Dec 2020 19:25:16 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <375474DC-8065-466C-82DB-37753572CE2C@yahoo.com> References: <3A095111-BE41-424A-AC51-DC848040C6B7@yahoo.com> To: Kurt Jaeger X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D6VlQ66xHz4qGF X-Spamd-Bar: - X-Spamd-Result: default: False [-1.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.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]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[98.137.68.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.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, 01 Jan 2021 03:25:24 -0000 On 2020-Dec-31, at 14:17, Mark Millard wrote: > On 2020-Dec-31, at 05:08, Kurt Jaeger wrote: >=20 >> Hello, >>=20 >> Roland posted a patch to build databases/cassandra4 on arm64.aarch64 = in >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252068 >> and I built it on my 13-jail: >>=20 >> arm 13.0-CURRENT 1300132 r368817 arm64.aarch64 svn+ssh = 2020-12-20 10:38:52 /pou/jails/arm >>=20 >> The build fails almost at the end with: >>=20 >> cd = /wrkdirs/usr/ports/databases/cassandra4/work/apache-cassandra-4.0-beta2-sr= c/build/dist && /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio = -dumpl $2 >/dev/null 2>&1) && /usr/bin/find -Ed $1 $3 \( -type d = -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} + -o = -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + = \)' COPYTREE_SHARE javadoc = /wrkdirs/usr/ports/databases/cassandra4/work/stage/usr/local/share/doc/cas= sandra/ >> find: /bin/sh: Argument list too long >> *** Error code 1 >>=20 >> and Ronald compared it to a build on amd64. He found that my jail has >> a surprising small data seg size: >>=20 >> data seg size (kbytes, -d) 131072 >>=20 >> Any ideas on how to raise the data seg size in the poudriere jail ? >>=20 >=20 > What does rctl report? (Not that I've ever used RACCT/RCTL.) >=20 > # rctl > rctl: RACCT/RCTL present, but disabled; enable using = kern.racct.enable=3D1 tunable >=20 > =46rom what I read in man rctl, "jail" is one of the "subject" = categories and > "datasize" is one of the "resources". So it looks like rctl is one of = the ways > a specific limit could be imposed. >=20 > I'm guessing you would look/control from outside the jail. Looks like for all but amd64, 128 MiByte is the default data seg size: # grep -r DFLDSIZ sys/*/include/vmparam.h=20 sys/amd64/include/vmparam.h:#ifndef DFLDSIZ sys/amd64/include/vmparam.h:#define DFLDSIZ = (32768UL*1024*1024) /* initial data size limit */ sys/arm/include/vmparam.h:#ifndef DFLDSIZ sys/arm/include/vmparam.h:#define DFLDSIZ = (128UL*1024*1024) /* initial data size limit */ sys/arm64/include/vmparam.h:#ifndef DFLDSIZ sys/arm64/include/vmparam.h:#define DFLDSIZ (128*1024*1024) = /* initial data size limit */ sys/i386/include/vmparam.h:#ifndef DFLDSIZ sys/i386/include/vmparam.h:#define DFLDSIZ = (128UL*1024*1024) /* initial data size limit */ sys/mips/include/vmparam.h:#ifndef DFLDSIZ sys/mips/include/vmparam.h:#define DFLDSIZ = (128UL*1024*1024) /* initial data size limit */ sys/powerpc/include/vmparam.h:#ifndef DFLDSIZ sys/powerpc/include/vmparam.h:#define DFLDSIZ (128*1024*1024) = /* default data size */ sys/riscv/include/vmparam.h:#ifndef DFLDSIZ sys/riscv/include/vmparam.h:#define DFLDSIZ (128*1024*1024) = /* initial data size limit */ =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 1 13:26: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 CCAB64C8952 for ; Fri, 1 Jan 2021 13:26:51 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 4D6m5R0CSwz4pfh for ; Fri, 1 Jan 2021 13:26:50 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mail-ej1-x62c.google.com with SMTP id ce23so28033806ejb.8 for ; Fri, 01 Jan 2021 05:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=31bNX4t5VnyAZuGYBl+mVVVN4Pbm4WDXEKgu0iAY9Ck=; b=FKqqNzeoxX+qQRWVG1LLjPRPsWNNsNOH+B625IRJ6p1KcA7fWvXZGXEE4v+J03DErm iWL23Gb/lwmt/zJR/MgS5E+hCPLKtm3HwXnlllPVzGmY7hSrur4Sng9UKaP4XrxNjSCm DvmRLcyBqTVS1UcNDcQ0UOBioAEezEqrrZfoWukqk9DgKGtiLDlGsek/gGlhoZdDz9lM HX4eGi2CdkHeM99Y9evA9Kdl47mDbcu8shjdAHuNYVcpszW9C1ifoqoekMnwX68OLm9J pBG8lBjDw466gtbAI9TgTAvtv31rG57iEVds9JnKahNjvKFijRXBku2/AGqYKc7Mi475 wJ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=31bNX4t5VnyAZuGYBl+mVVVN4Pbm4WDXEKgu0iAY9Ck=; b=XcNI1LA5lSgCrfqwLyMzksQJOxAGBZIk3+URD6cHQxpEI1AMHegRxVqhry/xMvPcTC OFwNFhQwfaNUY7WJaNVafqozZFeWs0HKgQ2iK1CZYOM1GGShLsv59VcyDkBjbhg/2iaE X+9Uskb+jLBc8X8PH4JnBkzfq3WYlvP2Y1z1xsZVGfgyNkRjicx4pAjBYsor3VEMD7iO qfxkcnBsbzZNpNA2rZtKxk7TOeBWBxt8b7O5tByf2NKgANy9Wf4IhezQtQHpf/bpyAeU yB8gm4ktbSPTVM/fpdYo+xMJrFI8TcENU5GyAWVGRRXqKV8tNMe79eQK97iug8BvJ83w vupQ== X-Gm-Message-State: AOAM5310NwrGDVx+bom0yMsDkHFBK0mErZGdz/F5yopjpe1/IGRZGFPC ZCAIvJ0XZFxT02vpoACJn10CdmJID/s= X-Google-Smtp-Source: ABdhPJy+C1zJxTGiZZlWzS9h04jQtOwpjI1+S5poF7Ajn0qK1H6hUHEBzea+9srJHfuy8JxTj1wPww== X-Received: by 2002:a17:907:6e9:: with SMTP id yh9mr56848493ejb.131.1609507609360; Fri, 01 Jan 2021 05:26:49 -0800 (PST) Received: from mac.deepcore.dk ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id s19sm40799002edx.7.2021.01.01.05.26.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jan 2021 05:26:48 -0800 (PST) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Message-Id: Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: FreeBSD-13.0-CURRENT-arm64-aarch64-ROCKPRO64-20201210-7578a4862f0 broken ? Date: Fri, 1 Jan 2021 14:26:48 +0100 In-Reply-To: <20201231141821.274a45ffa0299cca5a7bb1f1@bidouilliste.com> To: freebsd-arm References: <4434862ed87c21113fb7f98636fe4694d73856ce.camel@freebsd.org> <0D6FCA87-F101-4AA0-A1BF-6EDBA003BC9F@gmail.com> <87B7940E-119D-4C7F-AB9D-0C78E7F8D3A3@gmail.com> <20201213180746.1224166dffb81cb6770ff80d@bidouilliste.com> <6784D541-8FED-4753-8631-B36886508165@gmail.com> <23CCE944-C9F0-42C9-8A93-DAC312FE01E2@gmail.com> <20201231141821.274a45ffa0299cca5a7bb1f1@bidouilliste.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Rspamd-Queue-Id: 4D6m5R0CSwz4pfh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=FKqqNzeo; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; 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::62c:from]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::62c:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=utf-8 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: Fri, 01 Jan 2021 13:26:51 -0000 > On 31 Dec 2020, at 14.18, Emmanuel Vadot > wrote: >=20 > On Thu, 31 Dec 2020 13:49:19 +0100 > S=C3=B8ren Schmidt > wrote: >=20 >> Hi gang >>=20 >> On my quest on getting the pinebookpro booting again I think I can = rule out u-boot for now. >=20 > I thought it was rockpro64 that gave you problems ? Those where solved with the latest 2021.01rc4 u-boot. I should have changed the subject, or rather I thought I did, got = interrupted 4 times during that mail by wife :) >=20 >> Back on the u-boot-2020.07 where a -current kernel from late = July/early august would boot just fine a current kernel fails to talk to = the SD card, the only change to an up to date current is not setting the = 800Hmz cpll clock and that is known not to make any difference. >=20 > How is it known that it doesn't make any difference ? There is no difference in behaviour, it fails exactly the same way. > cpll is one of the possible parent (and likely the default one) for > sd/emmc/sdio clocks. Doesn=E2=80=99t seem to affect anything but the clock for the display = from my poking around so far.. > Did you tested without this change ? Yes, plain -current with no changes as said above fails exactly the = same. >=20 >> Again the same SDcard works just dandy with net/openBSD also I 50Mhz = mode. 1 in 10 boots finds the card as 25Mhz and then it ?just works?. >>=20 >> Any Ideas ? >=20 > Cna you provide a boot verbose log please ? Sure, rather long though so I=E2=80=99ve uploaded the bits on=20 https://people.freebsd.org/~sos/PinebookPro = Including the odd drivers I=E2=80=99ve done / updated that=E2=80=99s = included in the working boots.. What have me intrigued is this in the early boot stage: --- verbose-success 2021-01-01 12:59:24.624917000 +0000 +++ verbose-fail 2021-01-01 13:03:21.444189000 +0000 @@ -831,7 +824,7 @@ gic0: CPU0 Re-Distributor woke up gic0: CPU0 enabled CPU interface via system registers its0: mem 0xfee20000-0xfee3ffff = on gic0 -rk_iodomain0: mem 0-0xff31ffff,0-0xfff on = rk_grf0 +rk_iodomain0: mem 0xff320000-0xff320fff on = rk_grf0 rk_iodomain1: mem 0-0xff76ffff,0-0xffff on = rk_grf1 rk_pinctrl0: on ofwbus0 gpio0: mem 0xff720000-0xff7200ff irq 71 = on rk_pinctrl0 And a litte later that interrupts are offset by 1 from here on: @@ -1017,7 +1004,7 @@ nvme0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0xfa000000 ofw_pci mapdev: start fa000000, len 16384 nvme0: attempting to allocate 5 MSI-X vectors (16 supported) -nvme0: using IRQs 77-81 for MSI-X +nvme0: using IRQs 78-82 for MSI-X nvme0: CapLo: 0x780100ff: MQES 255, CQR, TO 120 nvme0: CapHi: 0x00100030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX 1 nvme0: Version: 0x00010300: 1.3 -- S=C3=B8ren Schmidt sos@deepcore.dk / sos@freebsd.org = "So much code to hack, so little time=E2=80=9D From owner-freebsd-arm@freebsd.org Fri Jan 1 14:03:46 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 1ED724C8E6E for ; Fri, 1 Jan 2021 14:03:46 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6mw124hzz4rL2 for ; Fri, 1 Jan 2021 14:03:45 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from [5.83.10.113] (port=54100 helo=[10.0.30.30]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92.3) (envelope-from ) id 1kvL1n-0001rV-W0 for freebsd-arm@freebsd.org; Fri, 01 Jan 2021 14:03:44 +0000 To: freebsd-arm From: Andy McClements Subject: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? Message-ID: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> Date: Fri, 1 Jan 2021 14:03:37 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BlackCat-Spam-Score: 9 X-Spam-Status: No, score=0.9 X-Rspamd-Queue-Id: 4D6mw124hzz4rL2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ajm@ip-ether.net designates 2a00:1098:0:82:1000:0:2:1 as permitted sender) smtp.mailfrom=ajm@ip-ether.net X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1098:0:82:1000:0:2:1:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1098::82:1000:0:2:1]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ip-ether.net]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1098:0:82:1000:0:2:1:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[2a00:1098:0:82:1000:0:2:1:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:2a00:1098::/32, country:GB]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] 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, 01 Jan 2021 14:03:46 -0000 Hi, I'm new to FreeBSD on the RPI, so have been frantically reading old mailing-list posts and so on. I've managed to arrive at a fairly 'current' configuration which boots, but on which XHCI is broken. So I could do with some pointers. I have: RPI4B 8GB recent HW, v. 0xd03114 Bootloader: Sep 3 2020 Boot device: 32GB SDHC SD imaged with: FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20201210-7578a4862f0.img.xz config_RPI4.txt renamed to config.txt All RPI firmware files on the DOS partition updated from the Github master: https://github.com/raspberrypi/firmware/archive/master.zip U-Boot.bin replaced with the one which is supposed to have XHCI & 8Gb support, from: https://sourceforge.net/projects/rpi4uboot202010-fbsdonly-klaus/files/u-boot.bin The system boots up but the dmesg shows 'xhci firmware not found'. Dmesg: https://dmesgd.nycbug.org/index.cgi?do=view&id=5842 Not shown in the dmesg is the U-Boot output (below), wherin I suspect lies the smoking gun. I do not like the look of: "Bus xhci_pci: probe failed, error -110 No working controllers found" After a brief hunt I became filled with uncertainty about U-Boot and its support for FreeBSD on the RPI. So I though it best to check in here for advice. I did try the RPI4 SBBR UEFI firmware from https://rpi4-uefi.dev/about/, on a USB3.0 SSD, and that worked first time, but I've not yet put an OS on the SSD. Maybe that's now a better bootloader option for my needs than is U-Boot ? TIA, Andy -- U-Boot 2020.10-rc5 (Oct 05 2020 - 03:08:23 +0000) DRAM: 7.9 GiB RPI 4 Model B (0xd03114) MMC: mmc@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@7e300000.blk... Disk mmc@7e300000.blk not ready Scanning disk emmc2@7e340000.blk... ** Unrecognized filesystem type ** Found 3 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image 1182828 bytes read in 69 ms (16.3 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Dec 10 12:29:22 UTC 2020 root@releng1.nyi.freebsd.org) Command line arguments: loader.efi Image base: 0x39e0a000 EFI version: 2.80 EFI Firmware: Das U-Boot (rev 8224.4096) Console: comconsole (0) Load Path: /efi\boot\bootaa64.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,MBR,0xe3c2d5bd,0x81f,0x18fa8) Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,MBR,0xe3c2d5bd,0x81f,0x18fa8) Setting currdev to disk0p1: Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0xe3c2d5bd,0x197c7,0x3b58839) Setting currdev to disk0p2: Loading /boot/defaults/loader.conf Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local Loading kernel... /boot/kernel/kernel text=0x2a8 text=0x88211c text=0x1f2174 data=0x19cd48 data=0x0+0x5446f6 syms=[0x8+0x117780+0x8+0x13c5ab] Loading configured modules... /boot/entropy size=0x1000 /etc/hostid size=0x25 /boot/kernel/umodem.ko text=0x2120 text=0x1390 data=0x6e0+0x10 syms=[0x8+0xf48+0x8+0xb6e] loading required module 'ucom' /boot/kernel/ucom.ko text=0x21a0 text=0x2e20 data=0x880+0x858 syms=[0x8+0x11a0+0x8+0xb2c] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... From owner-freebsd-arm@freebsd.org Fri Jan 1 17:01: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 889CE4CDBCD for ; Fri, 1 Jan 2021 17:01:06 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6rrd3xcKz3Kp7 for ; Fri, 1 Jan 2021 17:01:05 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from [5.83.10.113] (port=59321 helo=[10.0.30.30]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92.3) (envelope-from ) id 1kvNnP-0005DT-Tr for freebsd-arm@freebsd.org; Fri, 01 Jan 2021 17:01:04 +0000 Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? To: freebsd-arm References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> From: Andy McClements Message-ID: <5621784b-2506-1216-f40e-4f1040989f3b@ip-ether.net> Date: Fri, 1 Jan 2021 17:00:58 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BlackCat-Spam-Score: 9 X-Spam-Status: No, score=0.9 X-Rspamd-Queue-Id: 4D6rrd3xcKz3Kp7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ajm@ip-ether.net designates 2a00:1098:0:82:1000:0:2:1 as permitted sender) smtp.mailfrom=ajm@ip-ether.net X-Spamd-Result: default: False [-1.62 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1098:0:82:1000:0:2:1:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1098::82:1000:0:2:1]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ip-ether.net]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1098:0:82:1000:0:2:1:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[2a00:1098:0:82:1000:0:2:1:from]; NEURAL_HAM_SHORT(-0.12)[-0.117]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:2a00:1098::/32, country:GB]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] 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, 01 Jan 2021 17:01:06 -0000 On 01/01/2021 14:03, Andy McClements wrote: > Hi, I'm new to FreeBSD on the RPI, so have been frantically reading old > mailing-list posts and so on. I've managed to arrive at a fairly > 'current' configuration which boots, but on which XHCI is broken. So I > could do with some pointers. Further, I've now tried the later 20201224 ISO (which contains a later U-Boot.bin) on the same hardware, with similar results to before: Config #2: RPI4B 8GB recent HW, v. 0xd03114 Bootloader: Sep 3 2020 Boot device: 32GB SDHC SD imaged with: FreeBSD-13.0-CURRENT-arm64-aarch64-RPI-20201224-3cc0c0d66a0-255241.img.xz Uboot.bin from the above ISO. All RPI firmware files on the DOS partition updated from the Github master: https://github.com/raspberrypi/firmware/archive/master.zip (Without the updated firmware I just got a crash loop in u-boot.) Dmesg #2: https://dmesgd.nycbug.org/index.cgi?do=view&id=5848 U-boot.bin output #2: U-Boot 2020.10 (Dec 24 2020 - 04:18:29 +0000) DRAM: 7.9 GiB RPI 4 Model B (0xd03114) MMC: mmc@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@7e300000.blk... Disk mmc@7e300000.blk not ready Scanning disk emmc2@7e340000.blk... ** Unrecognized filesystem type ** Found 3 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image 1183548 bytes read in 69 ms (16.4 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Dec 24 07:03:20 UTC 2020 root@releng1.nyi.freebsd.org) Command line arguments: loader.efi Image base: 0x39e0f000 EFI version: 2.80 EFI Firmware: Das U-Boot (rev 8224.4096) Console: comconsole (0) Load Path: /efi\boot\bootaa64.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,MBR,0xe3c2d098,0x81f,0x18fa8) Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,MBR,0xe3c2d098,0x81f,0x18fa8) Setting currdev to disk0p1: Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0xe3c2d098,0x197c7,0x5e6821) Setting currdev to disk0p2: Loading /boot/defaults/loader.conf Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local Loading kernel... /boot/kernel/kernel text=0x2a8 text=0x8861c8 text=0x1f2de4 data=0x19cf50 data=0x0+0x5446f6 syms=[0x8+0x117de0+0x8+0x13cad4] Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' /boot/kernel/umodem.ko text=0x2120 text=0x1390 data=0x6e0+0x10 syms=[0x8+0xf48+0x8+0xb6e] loading required module 'ucom' /boot/kernel/ucom.ko text=0x21a0 text=0x2e20 data=0x880+0x858 syms=[0x8+0x11a0+0x8+0xb2c] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... From owner-freebsd-arm@freebsd.org Fri Jan 1 17:05: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 39FCF4CDCEA for ; Fri, 1 Jan 2021 17:05:28 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (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 "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6rxf4pJGz3LXT for ; Fri, 1 Jan 2021 17:05:26 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Fri, 01 Jan 2021 17:05:14 +0000 To: Andy McClements , freebsd-arm From: Robert Crowston Reply-To: Robert Crowston Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? Message-ID: In-Reply-To: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> MIME-Version: 1.0 X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4D6rxf4pJGz3LXT X-Spamd-Bar: - X-Spamd-Result: default: False [-1.90 / 15.00]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[185.70.40.18:from]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; SPAMHAUS_ZRD(0.00)[185.70.40.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; AUTOGEN_PHP_SPAMMY(1.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.18:from]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 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: Fri, 01 Jan 2021 17:05:28 -0000 VGhlIHUtYm9vdCBvdXRwdXQgaXMgbm90IGEgc21va2luZyBndW47IHRoZSB1LWJvb3QgdmVyc2lv biBwYWNrYWdlZCB1cCB0aGVyZSBkaWQgbm90IGhhdmUgdGhlIGRyaXZlciBpbiBpdC4gVGhlIGZy ZWVic2QgZHJpdmVyIGlzIHNlcGFyYXRlIGFuZCBkb2VzIG5vdCBkZXBlbmQgb24gdS1ib290LgoK QXMgSSByZWNhbGwsIHRoYXQgd2FybmluZyBpbmRpY2F0ZXMgdGhhdCB3ZSB0cmllZCwgYnV0IGZh aWxlZCB0byBsb2FkIHRoZSBmaXJtd2FyZSwgd2hpY2ggSSBoYXZlbuKAmXQgc2VlbiBpbiB0aGUg d2lsZCBiZWZvcmUuIENvdWxkIHlvdSB0cnkgYm9vdGluZyBpbiB2ZXJib3NlIG1vZGU/CgpEbyB5 b3Uga25vdyB3aGF0IHZlcnNpb24gb2YgVVNCIGZpcm13YXJlIGlzIGluc3RhbGxlZCBvbiB0aGUg UGk/IEFsdGVybmF0aXZlbHksIHdoZW4gZGlkIHlvdSBwdXJjaGFzZSB0aGlzIGhhcmR3YXJlPyAo TXkgc3VzcGljaW9uIGlzIHRoYXQgdGhlIFBpIGZvdW5kYXRpb24gbW92ZWQgdGhlIGdvYWxwb3N0 cyBhZ2FpbiAuLi4pCgpZb3Ugc2F5IHRoaXMgd29ya3MgZmluZSB3aXRoIHRoZSBVRUZJIGJvb3Q/ IElmIHlvdSBjYW4gdXNlIGJvb3Qgd2l0aCB0aGF0IG9uZSwgaXQgd291bGQgYmUgZ29vZCB0byBz ZWUgaWYgaXQgd29ya3MuCgpSZTogc3RhdGUgb2YgdGhlIHBpIDQsIEkgZ3Vlc3Mgd2Ugc2hvdWxk IGJ1bmRsZSB1cCBhIHByb3BlciBpbWFnZSBvZiBpdCwgZWl0aGVyIGZvciBVU0IgZHJpdmUgb3Ig U0QgQ2FyZCwgaW5zdGVhZCBvZiB0ZWxsaW5nIHVzZXJzIHRvIHBlcmZvcm0gYWxsIHRoaXMgc3Vy Z2VyeS4KCuKAlCBSSEMuCgpPbiBGcmksIEphbiAxLCAyMDIxIGF0IDE0OjAzLCBBbmR5IE1jQ2xl bWVudHMgPGFqbUBpcC1ldGhlci5uZXQ+IHdyb3RlOgoKPiBIaSwgSSdtIG5ldyB0byBGcmVlQlNE IG9uIHRoZSBSUEksIHNvIGhhdmUgYmVlbiBmcmFudGljYWxseSByZWFkaW5nIG9sZAo+IG1haWxp bmctbGlzdCBwb3N0cyBhbmQgc28gb24uIEkndmUgbWFuYWdlZCB0byBhcnJpdmUgYXQgYSBmYWly bHkKPiAnY3VycmVudCcgY29uZmlndXJhdGlvbiB3aGljaCBib290cywgYnV0IG9uIHdoaWNoIFhI Q0kgaXMgYnJva2VuLiBTbyBJCj4gY291bGQgZG8gd2l0aCBzb21lIHBvaW50ZXJzLgo+Cj4gSSBo YXZlOgo+IFJQSTRCIDhHQiByZWNlbnQgSFcsIHYuIDB4ZDAzMTE0Cj4gQm9vdGxvYWRlcjogU2Vw IDMgMjAyMAo+IEJvb3QgZGV2aWNlOiAzMkdCIFNESEMKPiBTRCBpbWFnZWQgd2l0aDoKPiBGcmVl QlNELTEzLjAtQ1VSUkVOVC1hcm02NC1hYXJjaDY0LVJQSTMtMjAyMDEyMTAtNzU3OGE0ODYyZjAu aW1nLnh6Cj4gY29uZmlnX1JQSTQudHh0IHJlbmFtZWQgdG8gY29uZmlnLnR4dAo+IEFsbCBSUEkg ZmlybXdhcmUgZmlsZXMgb24gdGhlIERPUyBwYXJ0aXRpb24gdXBkYXRlZCBmcm9tIHRoZSBHaXRo dWIgbWFzdGVyOgo+IGh0dHBzOi8vZ2l0aHViLmNvbS9yYXNwYmVycnlwaS9maXJtd2FyZS9hcmNo aXZlL21hc3Rlci56aXAKPiBVLUJvb3QuYmluIHJlcGxhY2VkIHdpdGggdGhlIG9uZSB3aGljaCBp cyBzdXBwb3NlZCB0byBoYXZlIFhIQ0kgJiA4R2IKPiBzdXBwb3J0LCBmcm9tOgo+IGh0dHBzOi8v c291cmNlZm9yZ2UubmV0L3Byb2plY3RzL3JwaTR1Ym9vdDIwMjAxMC1mYnNkb25seS1rbGF1cy9m aWxlcy91LWJvb3QuYmluCj4KPiBUaGUgc3lzdGVtIGJvb3RzIHVwIGJ1dCB0aGUgZG1lc2cgc2hv d3MgJ3hoY2kgZmlybXdhcmUgbm90IGZvdW5kJy4KPgo+IERtZXNnOiBodHRwczovL2RtZXNnZC5u eWNidWcub3JnL2luZGV4LmNnaT9kbz12aWV3JmlkPTU4NDIKPgo+IE5vdCBzaG93biBpbiB0aGUg ZG1lc2cgaXMgdGhlIFUtQm9vdCBvdXRwdXQgKGJlbG93KSwgd2hlcmluIEkgc3VzcGVjdAo+IGxp ZXMgdGhlIHNtb2tpbmcgZ3VuLiBJIGRvIG5vdCBsaWtlIHRoZSBsb29rIG9mOgo+Cj4gIkJ1cyB4 aGNpX3BjaTogcHJvYmUgZmFpbGVkLCBlcnJvciAtMTEwCj4gTm8gd29ya2luZyBjb250cm9sbGVy cyBmb3VuZCIKPgo+IEFmdGVyIGEgYnJpZWYgaHVudCBJIGJlY2FtZSBmaWxsZWQgd2l0aCB1bmNl cnRhaW50eSBhYm91dCBVLUJvb3QgYW5kIGl0cwo+IHN1cHBvcnQgZm9yIEZyZWVCU0Qgb24gdGhl IFJQSS4KPgo+IFNvIEkgdGhvdWdoIGl0IGJlc3QgdG8gY2hlY2sgaW4gaGVyZSBmb3IgYWR2aWNl Lgo+Cj4gSSBkaWQgdHJ5IHRoZSBSUEk0IFNCQlIgVUVGSSBmaXJtd2FyZSBmcm9tIGh0dHBzOi8v cnBpNC11ZWZpLmRldi9hYm91dC8sCj4gb24gYSBVU0IzLjAgU1NELCBhbmQgdGhhdCB3b3JrZWQg Zmlyc3QgdGltZSwgYnV0IEkndmUgbm90IHlldCBwdXQgYW4gT1MKPiBvbiB0aGUgU1NELiBNYXli ZSB0aGF0J3Mgbm93IGEgYmV0dGVyIGJvb3Rsb2FkZXIgb3B0aW9uIGZvciBteSBuZWVkcwo+IHRo YW4gaXMgVS1Cb290ID8KPgo+IFRJQSwgQW5keQo+Cj4gLS0KPgo+IFUtQm9vdCAyMDIwLjEwLXJj NSAoT2N0IDA1IDIwMjAgLSAwMzowODoyMyArMDAwMCkKPgo+IERSQU06IDcuOSBHaUIKPiBSUEkg NCBNb2RlbCBCICgweGQwMzExNCkKPiBNTUM6IG1tY0A3ZTMwMDAwMDogMSwgZW1tYzJAN2UzNDAw MDA6IDAKPiBMb2FkaW5nIEVudmlyb25tZW50IGZyb20gRkFULi4uIEluOiBzZXJpYWwKPiBPdXQ6 IHZpZGNvbnNvbGUKPiBFcnI6IHZpZGNvbnNvbGUKPiBOZXQ6IGV0aDA6IGV0aGVybmV0QDdkNTgw MDAwCj4gUENJZSBCUkNNOiBsaW5rIHVwLCA1LjAgR2JwcyB4MSAoU1NDKQo+IHN0YXJ0aW5nIFVT Qi4uLgo+IEJ1cyB4aGNpX3BjaTogcHJvYmUgZmFpbGVkLCBlcnJvciAtMTEwCj4gTm8gd29ya2lu ZyBjb250cm9sbGVycyBmb3VuZAo+IEhpdCBhbnkga2V5IHRvIHN0b3AgYXV0b2Jvb3Q6IDAKPiBz d2l0Y2ggdG8gcGFydGl0aW9ucyAjMCwgT0sKPiBtbWMwIGlzIGN1cnJlbnQgZGV2aWNlCj4gU2Nh bm5pbmcgbW1jIDA6MS4uLgo+IEZvdW5kIEVGSSByZW1vdmFibGUgbWVkaWEgYmluYXJ5IGVmaS9i b290L2Jvb3RhYTY0LmVmaQo+IGxpYmZkdCBmZHRfY2hlY2tfaGVhZGVyKCk6IEZEVF9FUlJfQkFE TUFHSUMKPiBTY2FubmluZyBkaXNrIG1tY0A3ZTMwMDAwMC5ibGsuLi4KPiBEaXNrIG1tY0A3ZTMw MDAwMC5ibGsgbm90IHJlYWR5Cj4gU2Nhbm5pbmcgZGlzayBlbW1jMkA3ZTM0MDAwMC5ibGsuLi4K PiAqKiBVbnJlY29nbml6ZWQgZmlsZXN5c3RlbSB0eXBlICoqCj4gRm91bmQgMyBkaXNrcwo+IE5v IEVGSSBzeXN0ZW0gcGFydGl0aW9uCj4gQm9vdE9yZGVyIG5vdCBkZWZpbmVkCj4gRUZJIGJvb3Qg bWFuYWdlcjogQ2Fubm90IGxvYWQgYW55IGltYWdlCj4gMTE4MjgyOCBieXRlcyByZWFkIGluIDY5 IG1zICgxNi4zIE1pQi9zKQo+IGxpYmZkdCBmZHRfY2hlY2tfaGVhZGVyKCk6IEZEVF9FUlJfQkFE TUFHSUMKPiBCb290aW5nIC9lZmlcYm9vdFxib290YWE2NC5lZmkKPiBDb25zb2xlczogRUZJIGNv bnNvbGUKPiBSZWFkaW5nIGxvYWRlciBlbnYgdmFycyBmcm9tIC9lZmkvZnJlZWJzZC9sb2FkZXIu ZW52Cj4gU2V0dGluZyBjdXJyZGV2IHRvIGRpc2swcDE6Cj4gRnJlZUJTRC9hcm02NCBFRkkgbG9h ZGVyLCBSZXZpc2lvbiAxLjEKPiAoVGh1IERlYyAxMCAxMjoyOToyMiBVVEMgMjAyMCByb290QHJl bGVuZzEubnlpLmZyZWVic2Qub3JnKQo+Cj4gQ29tbWFuZCBsaW5lIGFyZ3VtZW50czogbG9hZGVy LmVmaQo+IEltYWdlIGJhc2U6IDB4MzllMGEwMDAKPiBFRkkgdmVyc2lvbjogMi44MAo+IEVGSSBG aXJtd2FyZTogRGFzIFUtQm9vdCAocmV2IDgyMjQuNDA5NikKPiBDb25zb2xlOiBjb21jb25zb2xl ICgwKQo+IExvYWQgUGF0aDogL2VmaVxib290XGJvb3RhYTY0LmVmaQo+IExvYWQgRGV2aWNlOgo+ IC9WZW5IdyhlNjFkNzNiOS1hMzg0LTRhY2MtYWVhYi04MmU4MjhmMzYyOGIpL1NEKDApL1NEKDAp L0hEKDEsTUJSLDB4ZTNjMmQ1YmQsMHg4MWYsMHgxOGZhOCkKPiBUcnlpbmcgRVNQOgo+IC9WZW5I dyhlNjFkNzNiOS1hMzg0LTRhY2MtYWVhYi04MmU4MjhmMzYyOGIpL1NEKDApL1NEKDApL0hEKDEs TUJSLDB4ZTNjMmQ1YmQsMHg4MWYsMHgxOGZhOCkKPiBTZXR0aW5nIGN1cnJkZXYgdG8gZGlzazBw MToKPiBUcnlpbmc6Cj4gL1Zlbkh3KGU2MWQ3M2I5LWEzODQtNGFjYy1hZWFiLTgyZTgyOGYzNjI4 YikvU0QoMCkvU0QoMCkvSEQoMixNQlIsMHhlM2MyZDViZCwweDE5N2M3LDB4M2I1ODgzOSkKPiBT ZXR0aW5nIGN1cnJkZXYgdG8gZGlzazBwMjoKPiBMb2FkaW5nIC9ib290L2RlZmF1bHRzL2xvYWRl ci5jb25mCj4gTG9hZGluZyAvYm9vdC9kZWZhdWx0cy9sb2FkZXIuY29uZgo+IExvYWRpbmcgL2Jv b3QvZGV2aWNlLmhpbnRzCj4gTG9hZGluZyAvYm9vdC9sb2FkZXIuY29uZgo+IExvYWRpbmcgL2Jv b3QvbG9hZGVyLmNvbmYubG9jYWwKPiBMb2FkaW5nIGtlcm5lbC4uLgo+IC9ib290L2tlcm5lbC9r ZXJuZWwgdGV4dD0weDJhOCB0ZXh0PTB4ODgyMTFjIHRleHQ9MHgxZjIxNzQgZGF0YT0weDE5Y2Q0 OAo+IGRhdGE9MHgwKzB4NTQ0NmY2IHN5bXM9WzB4OCsweDExNzc4MCsweDgrMHgxM2M1YWJdCj4g TG9hZGluZyBjb25maWd1cmVkIG1vZHVsZXMuLi4KPiAvYm9vdC9lbnRyb3B5IHNpemU9MHgxMDAw Cj4gL2V0Yy9ob3N0aWQgc2l6ZT0weDI1Cj4gL2Jvb3Qva2VybmVsL3Vtb2RlbS5rbyB0ZXh0PTB4 MjEyMCB0ZXh0PTB4MTM5MCBkYXRhPTB4NmUwKzB4MTAKPiBzeW1zPVsweDgrMHhmNDgrMHg4KzB4 YjZlXQo+IGxvYWRpbmcgcmVxdWlyZWQgbW9kdWxlICd1Y29tJwo+IC9ib290L2tlcm5lbC91Y29t LmtvIHRleHQ9MHgyMWEwIHRleHQ9MHgyZTIwIGRhdGE9MHg4ODArMHg4NTgKPiBzeW1zPVsweDgr MHgxMWEwKzB4OCsweGIyY10KPgo+IEhpdCBbRW50ZXJdIHRvIGJvb3QgaW1tZWRpYXRlbHksIG9y IGFueSBvdGhlciBrZXkgZm9yIGNvbW1hbmQgcHJvbXB0Lgo+IEJvb3RpbmcgWy9ib290L2tlcm5l bC9rZXJuZWxdLi4uCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwo+IGZyZWVic2QtYXJtQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdAo+IGh0dHBzOi8v bGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWFybQo+IFRvIHVuc3Vi c2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWFybS11bnN1YnNjcmliZUBmcmVlYnNk Lm9yZyI= From owner-freebsd-arm@freebsd.org Fri Jan 1 18:20: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 A65124CF834 for ; Fri, 1 Jan 2021 18:20:51 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6tcf658Xz3QpW for ; Fri, 1 Jan 2021 18:20:50 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from [5.83.10.113] (port=64866 helo=[10.0.30.30]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92.3) (envelope-from ) id 1kvP2b-0004bu-LX for freebsd-arm@freebsd.org; Fri, 01 Jan 2021 18:20:48 +0000 Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? To: freebsd-arm References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> From: Andy McClements Message-ID: Date: Fri, 1 Jan 2021 18:20:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BlackCat-Spam-Score: 9 X-Spam-Status: No, score=0.9 X-Rspamd-Queue-Id: 4D6tcf658Xz3QpW X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ajm@ip-ether.net designates 2a00:1098:0:86:1000:0:2:1 as permitted sender) smtp.mailfrom=ajm@ip-ether.net X-Spamd-Result: default: False [-0.58 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1098:0:86:1000:0:2:1:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1098::86:1000:0:2:1]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ip-ether.net]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1098:0:86:1000:0:2:1:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[2a00:1098:0:86:1000:0:2:1:from]; NEURAL_SPAM_SHORT(0.92)[0.923]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:2a00:1098::/32, country:GB]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] 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, 01 Jan 2021 18:20:51 -0000 On 01/01/2021 17:05, Robert Crowston wrote: > The u-boot output is not a smoking gun; the u-boot version packaged up > there did not have the driver in it. The freebsd driver is separate and > does not depend on u-boot. > > As I recall, that warning indicates that we tried, but failed to load > the firmware, which I haven’t seen in the wild before. Could you try > booting in verbose mode? Thanks Robert. Dmesg with 'boot -v' is at: https://dmesgd.nycbug.org/index.cgi?do=view&id=5849 The RPi4b was purchased last week from RS Components, and updated to the Sept 3rd firmware. A 'rollup' ISO for the RPi4 that includes all current fixes would be most welcomed. Andy From owner-freebsd-arm@freebsd.org Fri Jan 1 18:25: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 780524D008B for ; Fri, 1 Jan 2021 18:25:10 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6tjf2XVzz3R3X for ; Fri, 1 Jan 2021 18:25:10 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 3D0F32D2E0 for ; Fri, 1 Jan 2021 18:25:10 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f170.google.com with SMTP id g24so14588890qtq.12 for ; Fri, 01 Jan 2021 10:25:10 -0800 (PST) X-Gm-Message-State: AOAM531fuR8L1PtJ5murc0FZp/95USZyrxs/xDGe0F2BpT6p2g5KIY3d qkGZnyUoUuT1aAJ2AxJpNADFipNYc+uj7vUFNrM= X-Google-Smtp-Source: ABdhPJxCvaiJyOz8I4y2Q1a/jBPxT/y9ed9SBzlLNom1u9Iywfdtq1PGteLVm8v3taRiRI3hRIzePpKuDVtjNhWPmsY= X-Received: by 2002:ac8:7141:: with SMTP id h1mr61659041qtp.211.1609525509749; Fri, 01 Jan 2021 10:25:09 -0800 (PST) MIME-Version: 1.0 References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> In-Reply-To: From: Kyle Evans Date: Fri, 1 Jan 2021 12:24:58 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? To: Robert Crowston Cc: Andy McClements , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 01 Jan 2021 18:25:10 -0000 On Fri, Jan 1, 2021 at 11:05 AM Robert Crowston via freebsd-arm wrote: > > The u-boot output is not a smoking gun; the u-boot version packaged up th= ere did not have the driver in it. The freebsd driver is separate and does = not depend on u-boot. > > As I recall, that warning indicates that we tried, but failed to load the= firmware, which I haven=E2=80=99t seen in the wild before. Could you try b= ooting in verbose mode? > > Do you know what version of USB firmware is installed on the Pi? Alternat= ively, when did you purchase this hardware? (My suspicion is that the Pi fo= undation moved the goalposts again ...) > > You say this works fine with the UEFI boot? If you can use boot with that= one, it would be good to see if it works. > > Re: state of the pi 4, I guess we should bundle up a proper image of it, = either for USB drive or SD Card, instead of telling users to perform all th= is surgery. > What surgery are you referring to here? The -RPI image OP tried from the 24th is one that should boot as-is on all arm64 RPi variants without modification using the upstream U-Boot rpi arm64 config and a consolidated config.txt that conditionally does what's needed for the RPi4. From owner-freebsd-arm@freebsd.org Fri Jan 1 19:17: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 B818A4D12FC for ; Fri, 1 Jan 2021 19:17:58 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) (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 "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6vtZ3jqLz3k5y; Fri, 1 Jan 2021 19:17:57 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Fri, 01 Jan 2021 19:17:45 +0000 To: Kyle Evans From: Robert Crowston Cc: Andy McClements , freebsd-arm Reply-To: Robert Crowston Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? Message-ID: In-Reply-To: References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> MIME-Version: 1.0 X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4D6vtZ3jqLz3k5y X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 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: Fri, 01 Jan 2021 19:17:58 -0000 QXMgaXMgb2Z0ZW4gdGhlIGNhc2UsIEkgYW0gYmVoaW5kIHRoZSB0aW1lcy4gOi0pCgpBbmR5LCBj b3VsZCB5b3UgdHJ5IGJvb3Rpbmcgd2l0aCB0aGUgdW5tb2RpZmllZCwgdmFuaWxsYSBpbWFnZT8K CuKAlCBSSEMuCgpPbiBGcmksIEphbiAxLCAyMDIxIGF0IDE4OjI0LCBLeWxlIEV2YW5zIDxrZXZh bnNAZnJlZWJzZC5vcmc+IHdyb3RlOgoKPiBPbiBGcmksIEphbiAxLCAyMDIxIGF0IDExOjA1IEFN IFJvYmVydCBDcm93c3RvbiB2aWEgZnJlZWJzZC1hcm0KPiA8ZnJlZWJzZC1hcm1AZnJlZWJzZC5v cmc+IHdyb3RlOgo+Pgo+PiBUaGUgdS1ib290IG91dHB1dCBpcyBub3QgYSBzbW9raW5nIGd1bjsg dGhlIHUtYm9vdCB2ZXJzaW9uIHBhY2thZ2VkIHVwIHRoZXJlIGRpZCBub3QgaGF2ZSB0aGUgZHJp dmVyIGluIGl0LiBUaGUgZnJlZWJzZCBkcml2ZXIgaXMgc2VwYXJhdGUgYW5kIGRvZXMgbm90IGRl cGVuZCBvbiB1LWJvb3QuCj4+Cj4+IEFzIEkgcmVjYWxsLCB0aGF0IHdhcm5pbmcgaW5kaWNhdGVz IHRoYXQgd2UgdHJpZWQsIGJ1dCBmYWlsZWQgdG8gbG9hZCB0aGUgZmlybXdhcmUsIHdoaWNoIEkg aGF2ZW7igJl0IHNlZW4gaW4gdGhlIHdpbGQgYmVmb3JlLiBDb3VsZCB5b3UgdHJ5IGJvb3Rpbmcg aW4gdmVyYm9zZSBtb2RlPwo+Pgo+PiBEbyB5b3Uga25vdyB3aGF0IHZlcnNpb24gb2YgVVNCIGZp cm13YXJlIGlzIGluc3RhbGxlZCBvbiB0aGUgUGk/IEFsdGVybmF0aXZlbHksIHdoZW4gZGlkIHlv dSBwdXJjaGFzZSB0aGlzIGhhcmR3YXJlPyAoTXkgc3VzcGljaW9uIGlzIHRoYXQgdGhlIFBpIGZv dW5kYXRpb24gbW92ZWQgdGhlIGdvYWxwb3N0cyBhZ2FpbiAuLi4pCj4+Cj4+IFlvdSBzYXkgdGhp cyB3b3JrcyBmaW5lIHdpdGggdGhlIFVFRkkgYm9vdD8gSWYgeW91IGNhbiB1c2UgYm9vdCB3aXRo IHRoYXQgb25lLCBpdCB3b3VsZCBiZSBnb29kIHRvIHNlZSBpZiBpdCB3b3Jrcy4KPj4KPj4gUmU6 IHN0YXRlIG9mIHRoZSBwaSA0LCBJIGd1ZXNzIHdlIHNob3VsZCBidW5kbGUgdXAgYSBwcm9wZXIg aW1hZ2Ugb2YgaXQsIGVpdGhlciBmb3IgVVNCIGRyaXZlIG9yIFNEIENhcmQsIGluc3RlYWQgb2Yg dGVsbGluZyB1c2VycyB0byBwZXJmb3JtIGFsbCB0aGlzIHN1cmdlcnkuCj4+Cj4KPiBXaGF0IHN1 cmdlcnkgYXJlIHlvdSByZWZlcnJpbmcgdG8gaGVyZT8gVGhlIC1SUEkgaW1hZ2UgT1AgdHJpZWQg ZnJvbQo+IHRoZSAyNHRoIGlzIG9uZSB0aGF0IHNob3VsZCBib290IGFzLWlzIG9uIGFsbCBhcm02 NCBSUGkgdmFyaWFudHMKPiB3aXRob3V0IG1vZGlmaWNhdGlvbiB1c2luZyB0aGUgdXBzdHJlYW0g VS1Cb290IHJwaSBhcm02NCBjb25maWcgYW5kIGEKPiBjb25zb2xpZGF0ZWQgY29uZmlnLnR4dCB0 aGF0IGNvbmRpdGlvbmFsbHkgZG9lcyB3aGF0J3MgbmVlZGVkIGZvciB0aGUKPiBSUGk0Lg== From owner-freebsd-arm@freebsd.org Fri Jan 1 19:27:23 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 037624D1A3E for ; Fri, 1 Jan 2021 19:27:23 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6w5P6qmCz3l3p for ; Fri, 1 Jan 2021 19:27:21 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from [5.83.10.113] (port=55424 helo=[10.0.30.30]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92.3) (envelope-from ) id 1kvQ4x-000149-6u; Fri, 01 Jan 2021 19:27:19 +0000 Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? To: Robert Crowston References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> Cc: freebsd-arm From: Andy McClements Message-ID: <6420fc92-202f-6ea7-72eb-7868c6df032b@ip-ether.net> Date: Fri, 1 Jan 2021 19:27:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BlackCat-Spam-Score: 9 X-Spam-Status: No, score=0.9 X-Rspamd-Queue-Id: 4D6w5P6qmCz3l3p X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ajm@ip-ether.net designates 2a00:1098:0:82:1000:0:2:1 as permitted sender) smtp.mailfrom=ajm@ip-ether.net X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1098:0:82:1000:0:2:1:from]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1098::82:1000:0:2:1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ip-ether.net]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[2a00:1098:0:82:1000:0:2:1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[2a00:1098:0:82:1000:0:2:1:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:2a00:1098::/32, country:GB]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] 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, 01 Jan 2021 19:27:23 -0000 On 01/01/2021 19:17, Robert Crowston wrote: > As is often the case, I am behind the times. :-) > > Andy, could you try booting with the unmodified, vanilla image? Hi Robert, the notes I made earlier this afternoon tell me I just got a 'crash loop' in U-boot on my hardware with the vanilla '20201224' RPI disk image. Output quoted below. My RPi4b has the Sept 03 bootloader. This was fixed by overwriting the RPI firmware files in the DOS partition with the current files from: https://github.com/raspberrypi/firmware/archive/master.zip U-Boot 2020.10 (Dec 24 2020 - 04:18:29 +0000) DRAM: 7.9 GiB RPI 4 Model B (0xd03114) MMC: mmc@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found Hit any key to stop autoboot: 0 "Synchronous Abort" handler, esr 0x96000004 elr: 000000000009c0c8 lr : 0000000000092194 (reloc) elr: 000000003b3790c8 lr : 000000003b36f194 x0 : d519b040aa010000 x1 : 000000000000005c x2 : 0000000000800000 x3 : 000000003b3d3670 x4 : b900080152b00000 x5 : 000000000000005c x6 : 000000003b3d3670 x7 : b900080152afff90 x8 : 0000000000000000 x9 : 0000000000000008 x10: 00000000ffffffd0 x11: 0000000000000006 x12: 000000000001869f x13: 000000000000adcc x14: 000000003af4ce38 x15: 0000000000000002 x16: 0000000000004110 x17: 0000000000000000 x18: 000000003af58d90 x19: 000000003b3d30b0 x20: 0000000000000070 x21: 000000000000006d x22: 000000000000000a x23: 0000000000000005 x24: 000000003b3bf8ef x25: 000000003b3c7ad6 x26: 0000000000000000 x27: 000000000000006d x28: 000000003b3e4e94 x29: 000000003af4c100 Code: eb03005f 54ffff43 f9400ca4 17ffffe0 (f9400404) Resetting CPU ... resetting ... From owner-freebsd-arm@freebsd.org Fri Jan 1 20:59:50 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 EF56E4D3C7E for ; Fri, 1 Jan 2021 20:59:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.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 4D6y864scmz3qmF for ; Fri, 1 Jan 2021 20:59:50 +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=1609534789; bh=DhuE4YnPGTeStYK9E/UiP5DYGOvwk9MLswiH8d5G0rk=; h=Subject:From:Date:To:From:Subject; b=YMDp89rbZtFUo1i1WL+EqOpp68u4YV7Cnd0JfAizwcW2ZrLtCApwr4bc6iHZPnIXeAKlSAIOEAJoe/Y3ZPS0JEca7zzeE3N0igLY5UBwMBns192JC+bEYp4YzSW7LlSZCORIvkELFxxaPqRu7LUkrmjMjrHI6dLttmUwJaKX54U2l4Hx3N0mkIxQT94e5gYgdthij6hin+bAPRJ/InINaextaWcmzuai7hywk95n/5AmfGybNeRiQhxz9Uhc9bzb9Ka+nmY6a1PyBD05F37tQg0VZEWI1f9+wodMe4D3Q5iuwlJecePbLn1kWLLKFN3eSElQtNsazYs2sUyZgKO7dQ== X-YMail-OSG: mqNGG8MVM1kUEZXk1TguLsVzTeON1uW1rjDSvTuTUvb7zXnuRyuZCwrjplAYTVQ a6nX7OjJQ7laoN1WdND.1YKO9r6gyHUUOdIfSzaBqSt6fqgxxqkoz5R7TIM.sH8M8ptl5egqfVxc ViwkJvpKT7dtGhxLq_XlkzMLqwb85RuD1e.gKP0IboCY1K7PpqqfjHuCv_JMZAatmJgmu6bNSk3R ZOjF1bCpvzBNgW9Cvi73d.jE72IRMIW8pSG2Mc4qc4hntV4eo1.U0SlnllYLhcPQDvebgEmU_IWc EOewWhSvOsS97YwAzsquJf7nPxUCmg7qgFQ1ps.X_a3GYm1ZTQdXbl488cwrykJqCey0pJ1mAFjm _Q9LR395ZMRNI5BmaaHKI0UsOhQXM3ha5T5Zte8Ey.EDrk1TIACVOGiXggFLBOAAJgx90Ayc5.fH spImgIrHU0yMPShJk2jiA8lSOnvk.OlPD3Z46uVsq3899tffUIrR3VmihdyOWW8iufyMbZvxxdpO x5_55tj0BzuH1h0TDg7XvXxf53X9x1lh4.WWrZrQigLn17GZMvcGfYnZZcs9k9BlgHBgdIYHfQy0 OzlsRMOIZK9gIs8e._xstsPJE1q1CjfR3_HFGyrG1fT4FjcTCQoc578T4yv_18zKirEI.OOU53S9 _proS3ddFX4oiuViu4HfQaicX1rb9RS3xp2G2dzKXGJmw_SHTv3HKp.9ouNo_LkdVAWC85f1bM48 dqxqiBmPtENQt5Iy6PYAKdK7cYkyiLLqxktjuufx5raei5h1S9ETb5ri6Nr3okZ5Z1.SJWiqmc5t bZgx5IK76iZCs29U7tLEWZNvcQWX1so0Na8LpPSS8or3Ds3vhr244KAqwWhG4AM7N2Obdu4g_nvf ECwG77ggea5_MFTje3dVQkQbWNX4cWocA3CxG.aFC2SCTlrTmbFP_i97De7hTOV41WVZCqcAMC29 qOI4dqrIPb48vxtPlHnNDJO.Q8hhXdco0lXPp9GSIwzeuOByOBu_7BI6EYp.Trsuq_nlZxe4S3Tp 4X7HoFlff0TcW.X3WrW2Ax4DmW_qX_.mPkhSpKQFdkFaM9Bd8Yx7y1O.tVR70jbqJbDPlyd_3fAB v3VoWGmC_h2RwrLjlGAX05ZZVXCZcWHxlsHShXzdAWeKnS2o0E.W9o4qiRYtTS5lgoBPJHCk7EJP edxq2ew2cYP13wjDqhbi8zEwDQs4C1YE98A_.BUMpks_28rXnr3N1PszJ4zwk8mW0L.pt.KQHMkO .tcrJGGlAAYYB0R9Gbe90grMPtu7cUMKzUlFDfDE0gB8s.tznxXgMtue0oF3eTVflFxcVS_C_NyW uo4WXUkrqAsr0uEjDWBBJQckYGOTyBINqwrWFSShncecupg72b9.BmM5dFOfX_S5hIRah.QnWB8y jmbjHHUlPo9EZNh_X0PReF2uooFv0.PX0SR3_BXxCuINnV2C3PrL96asx52DjrSmBf0sb.iP6Mp8 x5wooEE789pXtA3Id5ofT6Hk75hTycCJhBx7wEbJI4V7PG55Ix33mZau3gv0Vn6rsMfNITyQFFYb MeAIZINCoegMO1tQ7bTWJJsgW0FSpjXqpbS2jreSgf6l_fN8A9sLUWAkLFaSXtPiCQDdsrzonW8V MUz2iSY3EOhhG3bNtA51kufS_rlSzRGLER7Svhq4qxgh4b84My8oXWhPf.7P5y2cLyOD5BW1wxHf 3Icd5er_jsskpOEbrF2DXOcoF2.bSqnjBVj6dv4oG8kdKhEar_hzqUsKZnv8TOjoS1uEdxIwSFnT G7.zkTru6kC8G4nOtSpUn6TdQDX1HnWWkuKl1LoVFbNwlvc59TFheLtoK.9bLEfZ_U8yngjtLtqN _mu9Lu4iwbeZIlFi8zxgtk5Ain.jQJXFUZIJgAgoLn1FWEZSA2IGcSq2Wc3TR8T6i.47WOd_9LbW cDAI1cPlG0W02woJ_fz8ulpdrAHgfJtOnJ9EEAG7KTXvnyuAdKeX2RSUuHfkKNvK1A3QgvACFsIS BlxQR_7AXBVusJ2DQKkoq9p8OOmmEvf3JpDazQ3qXseMFgHp6qRUhtctpXHoH__B3hPCpTpwW5b3 iGaxrn3UNPEPvfMm1vsSl6PzKqeQ1L_kARdUbi8buwQdUXKBIarZrgJtfwrScoEcwIZg0vXKy3o0 KejUF_4.l0EOz13Wn8ykOdJoLrI4TOGGlRMjXPHCp.h8u3w4z2SA3P5Ly1uYyDOLFgzmDoDHIevT 9bvh8TASBW7PoUR_01EIc3A0qEP1PaWOSUMjdtz5o8anR9nsmpeuCGJFz3adA06Os6sCUp0rFav6 MviPej9KWACWoee.FnAL_Jl3lIOCWf7_zZXF_RK6v2Rufgtqjx0fZet2k9TQu0s.uu8SZCdClHtk qanoBx0tCCknn1t9oSk_KJY.StQ_8cMX0HPsgdAwKdXJmZSIFNznxxUbqK79USWDD3bmr5yL3Ksj 2MKdFl1b7KY5zjvxI3w5WxA3tPYE9U8ASOhRf7H75xAKKrhIWVuL8_jVXrQp0hF6XM3s_s7I0IuG JutSc25ki9jmv7mFkhsmGS_4ScN5VE7iquZ17jYx8jlvFydWApYpvhNr3b_q7G6ZNH9FQjij3Wah XmFgrllbx2Alrn2VT1potRgt5Y5tUUOg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 1 Jan 2021 20:59:49 +0000 Received: by smtp406.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4ea31491c80c806ddecef0ced831b0b5; Fri, 01 Jan 2021 20:59:47 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? From: Mark Millard In-Reply-To: Date: Fri, 1 Jan 2021 12:59:45 -0800 Cc: Robert Crowston , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> To: Kyle Evans X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D6y864scmz3qmF X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] 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, 01 Jan 2021 20:59:51 -0000 On 2021-Jan-1, at 10:24, Kyle Evans wrote: > On Fri, Jan 1, 2021 at 11:05 AM Robert Crowston via freebsd-arm > wrote: >>=20 >> The u-boot output is not a smoking gun; the u-boot version packaged = up there did not have the driver in it. The freebsd driver is separate = and does not depend on u-boot. >>=20 >> As I recall, that warning indicates that we tried, but failed to load = the firmware, which I haven=E2=80=99t seen in the wild before. Could you = try booting in verbose mode? >>=20 >> Do you know what version of USB firmware is installed on the Pi? = Alternatively, when did you purchase this hardware? (My suspicion is = that the Pi foundation moved the goalposts again ...) >>=20 >> You say this works fine with the UEFI boot? If you can use boot with = that one, it would be good to see if it works. >>=20 >> Re: state of the pi 4, I guess we should bundle up a proper image of = it, either for USB drive or SD Card, instead of telling users to perform = all this surgery. >>=20 >=20 > What surgery are you referring to here? The -RPI image OP tried from > the 24th is one that should boot as-is on all arm64 RPi variants > without modification using the upstream U-Boot rpi arm64 config and a > consolidated config.txt that conditionally does what's needed for the > RPi4. I'm not aware of any unpatched version of u-boot for FreeBSD yet that has bdinfo showing u-boot itself reserving all the RAM required for armstub8-gic.bin and its operation --so that u-boot guarantees to not touch that RAM. This is a different issue from the one of keeping the FreeBSD kernel from touching RAM it should not touch. In essence armstub_rsrvd is not being respected because it is ignored. (I might misremember the terminology but the wording is suggestive.) An example from u-boot bdinfo output is: lmb_dump_all: memory.cnt =3D 0x3 memory.size =3D 0x0 memory.reg[0x0].base =3D 0x0 .size =3D 0x3e000000 memory.reg[0x1].base =3D 0x40000000 .size =3D 0xbc000000 memory.reg[0x2].base =3D 0x100000000 .size =3D 0x100000000 reserved.cnt =3D 0x2 reserved.size =3D 0x0 reserved.reg[0x0].base =3D 0x0 .size =3D 0x1000 reserved.reg[0x1].base =3D 0x3db4bb30 .size =3D 0x4b44d0 I reported the above as a hypothesis for something that might have been involved in the fairly early "Synchronous Abort" crashes that I reported on the lists sometime around 2020-Dec-17 or so for my attempt to use /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin to set up a 8GiByte RPi4B. (My initial report confused the u-boot vs. FreeBSD kernel issue and I later replied noting that mistake.) Back in mid 2020-Oct I had written and posted patches for this lack of reservation but I was unsure about its upstream viability: QUOTE (There may be whitespace issues.) I doubt that the patches below are appropriate to upstream in some respects. It is more targeted at being a sysutils/u-boot-rpi[34] patch because what armstub8*.bin supplies in x1 seems specific to the armstub8*.bin FreeBSD uses. . . . # more = /usr/ports/sysutils/u-boot-rpi4/files/patch-board__raspberrypi__rpi__lowle= vel_init.S=20 --- board/raspberrypi/rpi/lowlevel_init.S.orig 2020-10-05 = 08:15:32.000000000 -0700 +++ board/raspberrypi/rpi/lowlevel_init.S 2020-10-13 = 11:33:39.273950000 -0700 @@ -18,9 +18,22 @@ #ifdef CONFIG_ARM64 adr x8, fw_dtb_pointer str x0, [x8] +#if defined(CONFIG_EFI_LOADER) + /* Setup to allow reserving the stack and such that is */ + /* after the likes of FreeBSD armstub8-gic.bin in RAM. */ + adr x8, armstub_rsrvd + str x1, [x8] +#endif #else ldr r8, =3Dfw_dtb_pointer str r2, [r8] +#if defined(CONFIG_EFI_LOADER) +#error "Before aarch64 does not use armstub*.bin files" + /* Setup to allow reserving the stack and such that is */ + /* after the likes of a armstub*.bin in RAM. */ + ldr r8, =3Darmstub_rsrvd + str r3, [r8] +#endif #endif /* Returns */ # more = /usr/ports/sysutils/u-boot-rpi4/files/patch-board__raspberrypi__rpi__rpi.c= =20 --- board/raspberrypi/rpi/rpi.c.orig 2020-10-05 08:15:32.000000000 = -0700 +++ board/raspberrypi/rpi/rpi.c 2020-10-13 11:02:15.582706000 -0700 @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -33,6 +34,7 @@ * does not get cleared later. */ unsigned long __section(".data") fw_dtb_pointer; +unsigned long __section(".data") armstub_rsrvd; /* TODO(sjg@chromium.org): Move these to the msg.c file */ struct msg_get_arm_mem { @@ -494,4 +496,29 @@ #endif return 0; +} + +void board_lmb_reserve(struct lmb *lmb) +{ +#ifdef CONFIG_EFI_LOADER + /* + * NOTE: lmb_reserve (and more) does not deal with overlaps with + * pre-existing reservations. + * But board_lmb_reserve is called before the original + * first-page is added. So use knowledge of what will = happen + * later to avoid overlaps. + */ + + phys_addr_t base =3D 0x0u; + phys_addr_t size =3D CONFIG_RPI_EFI_NR_SPIN_PAGES << = EFI_PAGE_SHIFT; + if (size < armstub_rsrvd) size =3D armstub_rsrvd; + + if (size <=3D EFI_PAGE_SIZE) return; + + /* Avoid future overlap */ + base +=3D EFI_PAGE_SIZE; + size -=3D EFI_PAGE_SIZE; + + lmb_reserve(lmb, base, size); +#endif } ENDQUOTE =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 2 10:21: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 2FBB34C9FF7 for ; Sat, 2 Jan 2021 10:21:10 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 4D7Hwj3Wllz3hGq for ; Sat, 2 Jan 2021 10:21:09 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x32c.google.com with SMTP id q75so13354077wme.2 for ; Sat, 02 Jan 2021 02:21:09 -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:message-id:references:to:date; bh=S8IrWaOVC40uUWOsU8/xAkRSN0x6LoDfwR4dsNjouOc=; b=e8NV8sEFdIjL/L5JxkFHzG5pgtNd+VzTdpoeJxCDAw9Fh5ePkFU+e+n69SQzNAtYrM yxGLKkTM77PuGETDd73mKdbB2Kj3S8bka5euf78gzQYObRfsmVf2ULV/uLtKE+aPX6hE 2fgHYWwDZdRhWMc2NWjDsOW/tkVYISj8hlZT5F1NX1HUZ92iJzb/ZEFay3+3EU8UH8oM iqvSk+P4kFzxVU0Lv8ncfgq+85OXBufBPcRIVj5cI2eTep9478uIr6Sat+A32pOONNjP VraHB+F60alAavUEsecoJW99I4TftlN6M6+JGEolXBAWAMTRbdUf9z71iYpavY8F8vf/ uDrA== X-Gm-Message-State: AOAM530Z2Ht58YSYo+ZutCQlsf0i2EII+bsX3hmuw6lp7ErJ7hF+dErH PEjZ66eHH5WI4afNNJs9pw8LUuT7BO5dxA== X-Google-Smtp-Source: ABdhPJxf9ux5LDLTBGkKD+4s5iz4RV0eS3FOr7bBUXVpDrtVpA/X2YNZSZNRUYKJjYFT/uc8TUZPlg== X-Received: by 2002:a1c:7c19:: with SMTP id x25mr19055274wmc.94.1609582455725; Sat, 02 Jan 2021 02:14:15 -0800 (PST) Received: from [192.168.1.167] (dynamic-046-114-106-160.46.114.pool.telefonica.de. [46.114.106.160]) by smtp.googlemail.com with ESMTPSA id m2sm21437949wml.34.2021.01.02.02.14.14 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Jan 2021 02:14:14 -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: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? Message-Id: <3D52896C-83FE-44FF-9293-A3008F660CA5@googlemail.com> References: To: freebsd-arm@freebsd.org Date: Sat, 2 Jan 2021 11:14:13 +0100 X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D7Hwj3Wllz3hGq X-Spamd-Bar: ++++++++ X-Spamd-Result: default: False [8.42 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,body]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[googlemail.com]; TO_DN_NONE(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(0.00)[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::32c:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.106.160:received]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.92)[0.923]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::32c:from:127.0.2.255]; BAD_REP_POLICIES(0.10)[]; RECEIVED_SPAMHAUS_CSS(4.00)[46.114.106.160:received]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32c:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-Spam: Yes 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, 02 Jan 2021 10:21:10 -0000 >> Am 01.01.2021 um 15:03 schrieb Andy McClements : >>=20 >>=20 >> Not shown in the dmesg is the U-Boot output (below), wherin I suspect >> lies the smoking gun. I do not like the look of: >>=20 >> "Bus xhci_pci: probe failed, error -110 >> No working controllers found=E2=80=9C >> =E2=80=A6.. >=20 > yeah,Andy,=20 > that gun stinks to the sky :-) , > if you want to get rid of that smoke see : > https://reviews.freebsd.org/D26853 > dtc -I dts -O dtb -o bcm2711-rpi-4-b.dtb bcm2711-rpi-4-b.dts > cp bcm2711-rpi-4-b.dtb /boot/msdos >=20 > Regards > Klaus >=20 >=20 From owner-freebsd-arm@freebsd.org Sat Jan 2 11:08:13 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 B69054CB649 for ; Sat, 2 Jan 2021 11:08:13 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7Jz03Xd7z3kPs for ; Sat, 2 Jan 2021 11:08:12 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from [5.83.10.113] (port=65139 helo=[10.0.30.30]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92.3) (envelope-from ) id 1kvelR-0000Iu-SE; Sat, 02 Jan 2021 11:08:10 +0000 Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? To: freebsd-arm References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> <6420fc92-202f-6ea7-72eb-7868c6df032b@ip-ether.net> From: Andy McClements Message-ID: Date: Sat, 2 Jan 2021 11:08:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6420fc92-202f-6ea7-72eb-7868c6df032b@ip-ether.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BlackCat-Spam-Score: 9 X-Spam-Status: No, score=0.9 X-Rspamd-Queue-Id: 4D7Jz03Xd7z3kPs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ajm@ip-ether.net designates 2a00:1098:0:82:1000:0:2:1 as permitted sender) smtp.mailfrom=ajm@ip-ether.net X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1098:0:82:1000:0:2:1:from]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1098::82:1000:0:2:1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ip-ether.net]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[2a00:1098:0:82:1000:0:2:1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[2a00:1098:0:82:1000:0:2:1:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:44684, ipnet:2a00:1098::/32, country:GB]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-arm]; FREEMAIL_CC(0.00)[protonmail.com] 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, 02 Jan 2021 11:08:13 -0000 On 01/01/2021 19:27, Andy McClements wrote: > On 01/01/2021 19:17, Robert Crowston wrote: >> As is often the case, I am behind the times. :-) >> >> Andy, could you try booting with the unmodified, vanilla image? > > Hi Robert, the notes I made earlier this afternoon tell me I just got a > 'crash loop' in U-boot on my hardware with the vanilla '20201224' RPI > disk image. Output quoted below. My RPi4b has the Sept 03 bootloader. > > This was fixed by overwriting the RPI firmware files in the DOS > partition with the current files from: > https://github.com/raspberrypi/firmware/archive/master.zip Just to check, I re-tested this using a USB3.0 SSD instead of the SD card. With the SSD, I get the crash loop in the 20201224 U-Boot, even *with* the latest RPI firmware copied over to the DOS partition. The output is more or less the same but with a couple of additions: "Card did not respond to voltage select!" "USB is stopped. Please issue 'usb start' first." With SSD: U-Boot 2020.10 (Dec 24 2020 - 04:18:29 +0000) DRAM: 7.9 GiB RPI 4 Model B (0xd03114) MMC: mmc@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found Hit any key to stop autoboot: 0 Card did not respond to voltage select! starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found USB is stopped. Please issue 'usb start' first. starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found "Synchronous Abort" handler, esr 0x96000044 elr: 000000000009bd2c lr : 0000000000091a10 (reloc) elr: 000000003b278d2c lr : 000000003b26ea10 x0 : 0000000000000000 x1 : b900080152b00000 x2 : 003aeea8f0000000 x3 : 0000000000000000 x4 : 000000003b2d30b0 x5 : 000000003aeea920 x6 : 0000000000000021 x7 : 656c696674646603 x8 : 0000000000000000 x9 : 0000000000000008 x10: 00000000ffffffd0 x11: 0000000000000006 x12: 000000000001869f x13: 00000000000069cc x14: 0000000000000000 x15: 00000000fffffffe x16: 0000000000004110 x17: 0000000000000000 x18: 000000003ae58d90 x19: 000000003b2d30b0 x20: 0000000000000030 x21: 0000000000000001 x22: 00000000ffffffff x23: 000000000000000b x24: 000000003b2bf8ef x25: 000000003b2c7ad6 x26: 0000000000000001 x27: 0000000000000020 x28: 000000003b2e4e94 x29: 000000003ae4c3e0 Code: f9400c02 927ef421 f9000c62 8b010001 (f9000843) Resetting CPU ... resetting ... (With SD card) > > U-Boot 2020.10 (Dec 24 2020 - 04:18:29 +0000) > > DRAM: 7.9 GiB > RPI 4 Model B (0xd03114) > MMC: mmc@7e300000: 1, emmc2@7e340000: 0 > Loading Environment from FAT... In: serial > Out: vidconsole > Err: vidconsole > Net: eth0: ethernet@7d580000 > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > starting USB... > Bus xhci_pci: probe failed, error -110 > No working controllers found > Hit any key to stop autoboot: 0 > "Synchronous Abort" handler, esr 0x96000004 > elr: 000000000009c0c8 lr : 0000000000092194 (reloc) > elr: 000000003b3790c8 lr : 000000003b36f194 > x0 : d519b040aa010000 x1 : 000000000000005c > x2 : 0000000000800000 x3 : 000000003b3d3670 > x4 : b900080152b00000 x5 : 000000000000005c > x6 : 000000003b3d3670 x7 : b900080152afff90 > x8 : 0000000000000000 x9 : 0000000000000008 > x10: 00000000ffffffd0 x11: 0000000000000006 > x12: 000000000001869f x13: 000000000000adcc > x14: 000000003af4ce38 x15: 0000000000000002 > x16: 0000000000004110 x17: 0000000000000000 > x18: 000000003af58d90 x19: 000000003b3d30b0 > x20: 0000000000000070 x21: 000000000000006d > x22: 000000000000000a x23: 0000000000000005 > x24: 000000003b3bf8ef x25: 000000003b3c7ad6 > x26: 0000000000000000 x27: 000000000000006d > x28: 000000003b3e4e94 x29: 000000003af4c100 > > Code: eb03005f 54ffff43 f9400ca4 17ffffe0 (f9400404) > Resetting CPU ... > > resetting ... > > > > > _______________________________________________ > 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 Sat Jan 2 13:10:54 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 A41BE4CFA0E for ; Sat, 2 Jan 2021 13:10:54 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 4D7MhY4K74z3sSx for ; Sat, 2 Jan 2021 13:10:53 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x42b.google.com with SMTP id i9so26400146wrc.4 for ; Sat, 02 Jan 2021 05:10:53 -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=cQP3iC8vI/KAXgXGkAVzGeBDHuLLVtNyYqo3qn+zHOY=; b=gW0CAQTgwWl1BaAHsPMujEzjEk1wxdQSJsMpqUnfirsY5LsCc+FImNIqcIBVwxx8Dr N2OrFL6XK0MO7JOBkDPqDv/t3sdob7IjZ3Os0CwNarwEAc+QeS2Vw6062b9053tDHkAE s4gpiwI8Psr4LmdoYRSnzpe+nS91kIcd+RaZE9jEefWNoBqLy+2/95r7ZpTS6/gWzY64 KImFfUyE7BX++nfufDycrJMAHfuR2MMzUOcaN+DAMQI8pkSQIUOZnF7ySfbjN6LZKNRv /LU5+Dqx59GIlMWp2KIoy2qZaobDehWDNFLCnYRsklL+yOT/knBMTKUtexfDHQk6v9/k VFMg== X-Gm-Message-State: AOAM533+Gefjh91gY0ByIuiJwkEP/x5Hq8pibvdl+mXr9QwpvRc2GzOY Wk5RMrQYyWI4GW8ABYVUyTuAnHdzvMFnxA== X-Google-Smtp-Source: ABdhPJyftSItJSXsZytQhcg7LSuAEJYjuqWdo80EXevWuyL9L+5ikF9myVgy9KNZjjjWEua8bQZukw== X-Received: by 2002:a5d:6045:: with SMTP id j5mr69852807wrt.223.1609593052258; Sat, 02 Jan 2021 05:10:52 -0800 (PST) Received: from [192.168.1.167] (dynamic-046-114-106-160.46.114.pool.telefonica.de. [46.114.106.160]) by smtp.googlemail.com with ESMTPSA id z21sm22228598wmk.20.2021.01.02.05.10.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Jan 2021 05:10:51 -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: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? Date: Sat, 2 Jan 2021 14:10:50 +0100 References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> <6420fc92-202f-6ea7-72eb-7868c6df032b@ip-ether.net> To: Andy McClements , freebsd-arm@freebsd.org In-Reply-To: Message-Id: <1F73BD49-837F-4008-B92B-10116E810CAD@googlemail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D7MhY4K74z3sSx X-Spamd-Bar: ++++++++ X-Spamd-Result: default: False [8.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,meta]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(0.00)[+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.00)[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::42b: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.00)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.106.160:received]; FROM_HAS_DN(0.00)[]; RECEIVED_SPAMHAUS_CSS(4.00)[46.114.106.160:received]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[0.998]; BAD_REP_POLICIES(0.10)[]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::42b:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.98)[0.981]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42b:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-Spam: Yes 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, 02 Jan 2021 13:10:54 -0000 I would be grateful to you if you could test : : https://reviews.freebsd.org/D26853 because your issue ---Bus xhci_pci: probe failed, error -110 disappear=E2=80=94 will be fixed with it . If you don=E2=80=99t know how to compile the dts, I could send you a compiled one , but better you do it yourself: > dtc -I dts -O dtb -o bcm2711-rpi-4-b.dtb bcm2711-rpi-4-b.dts Thanks in advance Klaus > Am 02.01.2021 um 12:08 schrieb Andy McClements : >=20 > On 01/01/2021 19:27, Andy McClements wrote: >> =E2=80=A6... > Bus xhci_pci: probe failed, error -110 > No working controllers found > USB is stopped. Please issue 'usb start' first. > starting USB... > Bus xhci_pci: probe failed, error -110 > No working controllers found > "Synchronous Abort" handler, esr 0x96000044 > elr: 000000000009bd2c lr : 0000000000091a10 (reloc) > elr: 000000003b278d2c lr : 000000003b26ea10 > x0 : 0000000000000000 x1 : b900080152b00000 > x2 : 003aeea8f0000000 x3 : 0000000000000000 > x4 : 000000003b2d30b0 x5 : 000000003aeea920 > x6 : 0000000000000021 x7 : 656c696674646603 > x8 : 0000000000000000 x9 : 0000000000000008 > x10: 00000000ffffffd0 x11: 0000000000000006 > x12: 000000000001869f x13: 00000000000069cc > x14: 0000000000000000 x15: 00000000fffffffe > x16: 0000000000004110 x17: 0000000000000000 > x18: 000000003ae58d90 x19: 000000003b2d30b0 > x20: 0000000000000030 x21: 0000000000000001 > x22: 00000000ffffffff x23: 000000000000000b > x24: 000000003b2bf8ef x25: 000000003b2c7ad6 > x26: 0000000000000001 x27: 0000000000000020 > x28: 000000003b2e4e94 x29: 000000003ae4c3e0 >=20 > Code: f9400c02 927ef421 f9000c62 8b010001 (f9000843) > Resetting CPU ... >=20 > resetting ... >=20 > >=20 >=20 >=20 >=20 >=20 > (With SD card) >> >> U-Boot 2020.10 (Dec 24 2020 - 04:18:29 +0000) >>=20 >> DRAM: 7.9 GiB >> RPI 4 Model B (0xd03114) >> MMC: mmc@7e300000: 1, emmc2@7e340000: 0 >> Loading Environment from FAT... In: serial >> Out: vidconsole >> Err: vidconsole >> Net: eth0: ethernet@7d580000 >> PCIe BRCM: link up, 5.0 Gbps x1 (SSC) >> starting USB... >> Bus xhci_pci: probe failed, error -110 >> No working controllers found >> Hit any key to stop autoboot: 0 >> "Synchronous Abort" handler, esr 0x96000004 >> elr: 000000000009c0c8 lr : 0000000000092194 (reloc) >> elr: 000000003b3790c8 lr : 000000003b36f194 >> x0 : d519b040aa010000 x1 : 000000000000005c >> x2 : 0000000000800000 x3 : 000000003b3d3670 >> x4 : b900080152b00000 x5 : 000000000000005c >> x6 : 000000003b3d3670 x7 : b900080152afff90 >> x8 : 0000000000000000 x9 : 0000000000000008 >> x10: 00000000ffffffd0 x11: 0000000000000006 >> x12: 000000000001869f x13: 000000000000adcc >> x14: 000000003af4ce38 x15: 0000000000000002 >> x16: 0000000000004110 x17: 0000000000000000 >> x18: 000000003af58d90 x19: 000000003b3d30b0 >> x20: 0000000000000070 x21: 000000000000006d >> x22: 000000000000000a x23: 0000000000000005 >> x24: 000000003b3bf8ef x25: 000000003b3c7ad6 >> x26: 0000000000000000 x27: 000000000000006d >> x28: 000000003b3e4e94 x29: 000000003af4c100 >>=20 >> Code: eb03005f 54ffff43 f9400ca4 17ffffe0 (f9400404) >> Resetting CPU ... >>=20 >> resetting ... >>=20 >> >>=20 >>=20 >> _______________________________________________ >> 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" >=20 > _______________________________________________ > 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 Sat Jan 2 14:02:19 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 B6A8A4D1203 for ; Sat, 2 Jan 2021 14:02:19 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 4D7Nqv064cz3w6N for ; Sat, 2 Jan 2021 14:02:18 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x42c.google.com with SMTP id m5so26420738wrx.9 for ; Sat, 02 Jan 2021 06:02:18 -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=3b7MdZU7OxHUhus86PPER8LmtxUNgCDGP3BuNkWaR+4=; b=B/TzF8TAHCzu2KIVg6XP/EcClaf45B2buKoKiwK9to62p/F8YzkM3BJjTnurfvJoq7 6DfAcARHqTB94a+HgVocLilixy0RHJ9Wm3XZ5Sbz9BeINR8zrgFS2I7b1D3WQ+CfwOQ0 K4NftlXA/sqXkhAYJ/7vNaw71s+AFddMwEbdbBuEbkwlaEqbBE1wsiTeufnpU1lQyEd+ RURdbO6XmzcyQM5Buil8BpV/Nku3fR3rqReQEnh9U0aipUcKCgqxVgZb0KEcWGLg/hbm zgB4iAc03esNeuJufw95CdH0M24QhN/V2cW0ShbJtULIuNst0VT6QeUZxXNDLCTm8C+D y3ZA== X-Gm-Message-State: AOAM533nJM1oNQJJJJpigpvxs00oIIl/BVJIZ6MEPDmApBtW0G2z+62S QqNhbUuxpaYLEVoQHjQGwA4= X-Google-Smtp-Source: ABdhPJw50qRfZoYwH0kKa0u33l6jz5Dvjj3oQD8FuNyMx1lpsTGvrRrVAg/0vQNCQypIblvLCJ7h6w== X-Received: by 2002:a5d:4d50:: with SMTP id a16mr70805591wru.43.1609596137186; Sat, 02 Jan 2021 06:02:17 -0800 (PST) Received: from [192.168.1.167] (dynamic-046-114-106-160.46.114.pool.telefonica.de. [46.114.106.160]) by smtp.googlemail.com with ESMTPSA id k1sm79944941wrn.46.2021.01.02.06.02.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Jan 2021 06:02:16 -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: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? Date: Sat, 2 Jan 2021 15:02:14 +0100 References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> <6420fc92-202f-6ea7-72eb-7868c6df032b@ip-ether.net> <1F73BD49-837F-4008-B92B-10116E810CAD@googlemail.com> <01acd32c-f525-61ee-bdb9-81f380da68a2@ip-ether.net> To: Andy McClements , freebsd-arm@freebsd.org In-Reply-To: <01acd32c-f525-61ee-bdb9-81f380da68a2@ip-ether.net> Message-Id: <6561AD02-1152-4400-A649-42C214690ED3@googlemail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D7Nqv064cz3w6N X-Spamd-Bar: ++++++++ X-Spamd-Result: default: False [8.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,meta]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(0.00)[+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.00)[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::42c: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.00)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.106.160:received]; FROM_HAS_DN(0.00)[]; RECEIVED_SPAMHAUS_CSS(4.00)[46.114.106.160:received]; NEURAL_SPAM_SHORT(1.00)[0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; BAD_REP_POLICIES(0.10)[]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::42c:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.995]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-Spam: Yes 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, 02 Jan 2021 14:02:19 -0000 Hi Andy, I have uploaded a precompiled bcm2711-rpi-4-b-dtb to : = https://sourceforge.net/projects/d26853-bcm2711-rpi-4-b-dtb/files/bcm2711-= rpi-4-b.dtb/download You just have to replace the one on the msdos-partition with it . `hope it will fix your issue and `hope we won=E2=80=99t find other = issues and i look forward to your dmesg, thanks in advance for testing Regards K. > Am 02.01.2021 um 14:47 schrieb Andy McClements : >=20 > On 02/01/2021 13:10, Klaus K=C3=BCchemann wrote: >> I would be grateful to you if you >> could test : : https://reviews.freebsd.org/D26853 >> because >> your issue ---Bus xhci_pci: probe failed, error -110 disappear=E2=80=94= >> will be fixed with it . >> If you don=E2=80=99t know how to compile the dts, >> I could send you a compiled one , but better you do it yourself: >>> dtc -I dts -O dtb -o bcm2711-rpi-4-b.dtb bcm2711-rpi-4-b.dts >>=20 >>=20 >> Thanks in advance >> Klaus >=20 > I just saw D26853 is alive again ! Cool ! >=20 > Andy > Am 02.01.2021 um 14:45 schrieb Andy McClements : Or, = perhaps you might oblige me, by sending me a compiled one ? From owner-freebsd-arm@freebsd.org Sat Jan 2 14:10:48 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 2FE874D12C7 for ; Sat, 2 Jan 2021 14:10:48 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 4D7P1f5vYzz3wY4 for ; Sat, 2 Jan 2021 14:10:46 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x42d.google.com with SMTP id t16so26485613wra.3 for ; Sat, 02 Jan 2021 06:10:46 -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:mime-version:subject:date:references:to :in-reply-to:message-id; bh=2MCHinXT1TovKo7ZUBHDvdzYOwCV7EAo4NMkxnT+GiQ=; b=Q9gZ7nF6WWq+ygtzyBDNerufYGN57iQVaSf6vDVt8OicjY6MeU4Ki+Jl62hTM87ebI HxfMLay9c7A/+m/XNdqCWrRPHz0q6sofScityRKvDG/HPLR5HfI05hpkhi537MhR/PGY /WDNLDDPHQ1/3NXqeAufFe8RM81I2NXZHk134N7YuuHpE0QQ1QKxjmtFphbsjVc5hbwe Pu0CuEP1iDY1McBAZvk/QnTUFRBzgyr8VaLJGU9tCwEmA9+WIa6f+NupEF4ZX3VvNHoD KRZRW0KU3+oMtoXXgn2//QSEj4/ehCqgANwOsYuY0MkjYS+HDp54L95dOVhotHQq+IHL bnCA== X-Gm-Message-State: AOAM53372pSC94JST/iArO4CMq4FDDuzZagelVeI6UWH24uVv0vZNH2c PsT9YEGALb3ZhrAJxRhLiQzmoFCDYPmY/w== X-Google-Smtp-Source: ABdhPJxF1CdrGBQU7bxifW0P+4rdaH4MFcam82CfPg8YTLxv6ZAcSYzZlQxB/T5ZFrHMebnYMPF/gg== X-Received: by 2002:adf:a4cf:: with SMTP id h15mr72856867wrb.13.1609596645321; Sat, 02 Jan 2021 06:10:45 -0800 (PST) Received: from [192.168.1.167] (dynamic-046-114-106-160.46.114.pool.telefonica.de. [46.114.106.160]) by smtp.googlemail.com with ESMTPSA id o7sm81336805wrw.62.2021.01.02.06.10.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Jan 2021 06:10:44 -0800 (PST) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? Date: Sat, 2 Jan 2021 15:10:42 +0100 References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> <6420fc92-202f-6ea7-72eb-7868c6df032b@ip-ether.net> <1F73BD49-837F-4008-B92B-10116E810CAD@googlemail.com> <01acd32c-f525-61ee-bdb9-81f380da68a2@ip-ether.net> <6561AD02-1152-4400-A649-42C214690ED3@googlemail.com> <0aabab1f-0ed6-1a8f-5add-c1886172ea4f@ip-ether.net> To: Andy McClements , freebsd-arm@freebsd.org In-Reply-To: <0aabab1f-0ed6-1a8f-5add-c1886172ea4f@ip-ether.net> Message-Id: <55582D66-E649-45EC-868E-DACEC8380780@googlemail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D7P1f5vYzz3wY4 X-Spamd-Bar: ++++++++ X-Spamd-Result: default: False [8.42 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,meta]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(0.00)[+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.00)[googlemail.com,quarantine]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::42d: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.00)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_CSS(4.00)[46.114.106.160:received]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.92)[0.920]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; BAD_REP_POLICIES(0.10)[]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::42d:from:127.0.2.255]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.106.160:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.996]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42d:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-Spam: Yes Content-Type: text/plain; charset=utf-8 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: Sat, 02 Jan 2021 14:10:48 -0000 Thanks Andy, have a nice shopping :-) Please reply to the list and you can send dmesg to : https://dmesgd.nycbug.org/index.cgi = I have uploaded the dtb in a hurry because I also want to go shopping = now :-) Regards K. > Am 02.01.2021 um 15:07 schrieb Andy McClements : >=20 > Hi Klaus, >=20 > Thanks ! I must just go out now to do some shopping, but will check it = later this afternoon. Shall I reply back to the list with the results or = to you directly ? >=20 > Andy >=20 > On 02/01/2021 14:02, Klaus K=C3=BCchemann wrote: >> Hi Andy, >>=20 >> I have uploaded a precompiled bcm2711-rpi-4-b-dtb to : >>=20 >> = https://sourceforge.net/projects/d26853-bcm2711-rpi-4-b-dtb/files/bcm2711-= rpi-4-b.dtb/download >>=20 >> You just have to replace the one on the msdos-partition with it . >> `hope it will fix your issue and `hope we won=E2=80=99t find other = issues >> and i look forward to your dmesg, >> thanks in advance for testing >>=20 >> Regards >> K. >>=20 >>=20 >>=20 >>=20 >>> Am 02.01.2021 um 14:47 schrieb Andy McClements : >>>=20 >>> On 02/01/2021 13:10, Klaus K=C3=BCchemann wrote: >>>> I would be grateful to you if you >>>> could test : : https://reviews.freebsd.org/D26853 >>>> because >>>> your issue ---Bus xhci_pci: probe failed, error -110 disappear=E2=80= =94 >>>> will be fixed with it . >>>> If you don=E2=80=99t know how to compile the dts, >>>> I could send you a compiled one , but better you do it yourself: >>>>> dtc -I dts -O dtb -o bcm2711-rpi-4-b.dtb bcm2711-rpi-4-b.dts >>>>=20 >>>>=20 >>>> Thanks in advance >>>> Klaus >>>=20 >>> I just saw D26853 is alive again ! Cool ! >>>=20 >>> Andy >>> Am 02.01.2021 um 14:45 schrieb Andy McClements : = Or, perhaps you might oblige me, by sending me a compiled one ? >>=20 >=20 From owner-freebsd-arm@freebsd.org Sat Jan 2 17:35:38 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 C4CB74D87CB for ; Sat, 2 Jan 2021 17:35:38 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7TZ16Pnlz4hgS for ; Sat, 2 Jan 2021 17:35:37 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from [5.83.10.113] (port=53203 helo=[10.0.30.30]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92.3) (envelope-from ) id 1kvkoO-00022G-CS for freebsd-arm@freebsd.org; Sat, 02 Jan 2021 17:35:36 +0000 Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> From: Andy McClements To: freebsd-arm Message-ID: Date: Sat, 2 Jan 2021 17:35:28 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BlackCat-Spam-Score: 9 X-Spam-Status: No, score=0.9 X-Rspamd-Queue-Id: 4D7TZ16Pnlz4hgS X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ajm@ip-ether.net designates 2a00:1098:0:82:1000:0:2:1 as permitted sender) smtp.mailfrom=ajm@ip-ether.net X-Spamd-Result: default: False [-0.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1098:0:82:1000:0:2:1:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1098::82:1000:0:2:1]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ip-ether.net]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1098:0:82:1000:0:2:1:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[2a00:1098:0:82:1000:0:2:1:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:2a00:1098::/32, country:GB]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] 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, 02 Jan 2021 17:35:38 -0000 On 02/01/2021 10:10, Klaus Küchemann wrote: > if you want to get rid of that smoke see : > https://reviews.freebsd.org/D26853 > dtc -I dts -O dtb -o bcm2711-rpi-4-b.dtb bcm2711-rpi-4-b.dts > cp bcm2711-rpi-4-b.dtb /boot/msdos I've tried four more tests, using a version of bcm2711-rpi-4-b.dtb with the D26853 patch applied. Briefly, with the patch, my RPi4B will now attach the USB controller and all dependant devices including genet0, and an attached SSD. The only thing that failed to work, was actually booting from the SSD with no SD card present, this caused a crash in U-boot. Details follow including links to the dmesgs. Hardware & OS image same as before: HW: RPi4b 8GB, late 2020 purchase, Sept 03 bootloader flashed OS: FreeBSD-13.0-CURRENT-arm64-aarch64-RPI-20201224-3cc0c0d66a0-255241.img.xz Test 5: Boot device: 32GB SD card U-Boot: 20201224 RPI firmware: 20201224 bcm2711-rpi-4-b-dtb replaced with D26853 patched version Result: Boots OK. USB all working. Dmesg: https://dmesgd.nycbug.org/index.cgi?do=view&id=5852 Test 6: Boot device: 32GB SD card U-Boot: 20201224 RPI firmware: DOS partition files replaced with those from 'firmware-master.zip' bcm2711-rpi-4-b-dtb replaced with D26853 patched version Result: Boots OK. USB all working. Dmesg: https://dmesgd.nycbug.org/index.cgi?do=view&id=5853 Test 7: Boot device: 120GB USB3.0 SSD U-Boot: 20201224 RPI firmware: DOS partition files replaced with those from 'firmware-master.zip' bcm2711-rpi-4-b-dtb replaced with D26853 patched version Result: U-boot crash loop U-Boot 2020.10 (Dec 24 2020 - 04:18:29 +0000) DRAM: 7.9 GiB RPI 4 Model B (0xd03114) MMC: mmc@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found Hit any key to stop autoboot: 0 Card did not respond to voltage select! starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found USB is stopped. Please issue 'usb start' first. starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found "Synchronous Abort" handler, esr 0x96000044 elr: 000000000009bd2c lr : 0000000000091a10 (reloc) elr: 000000003b278d2c lr : 000000003b26ea10 x0 : 0000000000000000 x1 : b900080152b00000 x2 : 003aeea8f0000000 x3 : 0000000000000000 x4 : 000000003b2d30b0 x5 : 000000003aeea920 x6 : 0000000000000021 x7 : 656c696674646603 x8 : 0000000000000000 x9 : 0000000000000008 x10: 00000000ffffffd0 x11: 0000000000000006 x12: 000000000001869f x13: 0000000000006198 x14: 0000000000000000 x15: 00000000fffffffe x16: 0000000000004110 x17: 0000000000000000 x18: 000000003ae58d90 x19: 000000003b2d30b0 x20: 0000000000000030 x21: 0000000000000001 x22: 00000000ffffffff x23: 000000000000000b x24: 000000003b2bf8ef x25: 000000003b2c7ad6 x26: 0000000000000001 x27: 0000000000000020 x28: 000000003b2e4e94 x29: 000000003ae4c480 Code: f9400c02 927ef421 f9000c62 8b010001 (f9000843) Resetting CPU ... resetting ... Test 8: Boot device: 32GB SD card Secondary disk device: USB 3.0 SSD U-Boot: 20201224 RPI firmware: DOS partition files replaced with those from 'firmware-master.zip' bcm2711-rpi-4-b-dtb replaced with D26853 patched version Result: Boots OK. USB all working. Second disk device is recognised. Dmesg: https://dmesgd.nycbug.org/index.cgi?do=view&id=5854 From owner-freebsd-arm@freebsd.org Sat Jan 2 17:51:08 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 4B4B14D9005 for ; Sat, 2 Jan 2021 17:51:08 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 4D7Tvv5brnz4jB1 for ; Sat, 2 Jan 2021 17:51:07 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x42d.google.com with SMTP id t30so26853219wrb.0 for ; Sat, 02 Jan 2021 09:51: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:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=TObvamW6BkcbIsHAa0d2m2ddf0h/8fdqc3BD11sDSw8=; b=PwNRFXH9bbq1zbAY6bhUYEI4s73/smdxAP6DKpZeq9WNyrgehPNnTj7B5H4HOPelSV Yz75NY7tj0m3WDlICMtnAxgxyrmBkKuigcrS58cxkeaAyvjZb33MIEqhNqPq99ItuWgr Jbm0kyIenrpWg9FpIF/gKab8u7f52OUJyeuwhascbDD/tiNAbc2bViVsG9V5OQ+EWRw7 yGy8LDcVQyv5MiXBF7HeW0qMNWFz0SwUlYSMwMBl9hvNmnBTE4Ke/VWzZx8KLxQ7eWrS OOThpv276Cuw3qX8276xSQBw1mWrP0p2Frm0HGYMM60kjA4230xa6Kodx8tO8rd4f/sE 7wKA== X-Gm-Message-State: AOAM531K6yk4H/D/uzYv+ao1gYTGjC5BHDhh426rAH3zxfQ9wJC5A88y Bz1Oy71nxquxtBNh9U0WKa5YFZgCjw8DXw== X-Google-Smtp-Source: ABdhPJxe1QoYav7YQuPURGW22MvoL5v2O2BYIsBFDRzDZMMoFY9f0k0X2f9X015+GgsagP/Fc0pDFQ== X-Received: by 2002:a5d:6852:: with SMTP id o18mr71533808wrw.371.1609609866315; Sat, 02 Jan 2021 09:51:06 -0800 (PST) Received: from [192.168.1.167] (dynamic-046-114-106-160.46.114.pool.telefonica.de. [46.114.106.160]) by smtp.googlemail.com with ESMTPSA id m5sm73541491wrz.18.2021.01.02.09.51.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Jan 2021 09:51:05 -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: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? Date: Sat, 2 Jan 2021 18:51:03 +0100 References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> To: Andy McClements , freebsd-arm@freebsd.org In-Reply-To: Message-Id: <5B626DCC-6F7C-4554-803C-F488A1ED9BEB@googlemail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D7Tvv5brnz4jB1 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::42d: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.106.160: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::42d:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42d: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: Sat, 02 Jan 2021 17:51:08 -0000 > Am 02.01.2021 um 18:35 schrieb Andy McClements : >=20 > was actually booting from the SSD with no SD card present, this caused = a crash in U-boot. >=20 Hi, thanks for testing ! ..and pleased to hear that we have made progress = =E2=80=A6 there seems to be something goin wrong with our release which doesn=E2=80=99= t embed the rpi-firmware correctly=20 In the rpi-release=E2=80=A6 Could you please test by overwriting the following files to the msdos - = partition : = https://github.com/raspberrypi/firmware/blob/master/boot/bcm2711-rpi-4-b.d= tb https://github.com/raspberrypi/firmware/blob/master/boot/start4.elf https://github.com/raspberrypi/firmware/blob/master/boot/fixup4.dat or better with all files which have the number 4 in it in : https://github.com/raspberrypi/firmware/tree/master/boot That should fix the SD-card-thing because I guess the dtb-fix made it = upstream meanwhile, If not we will continue hacking that... Thanks in advance=20 Regards K. From owner-freebsd-arm@freebsd.org Sat Jan 2 17:52: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 2CA834D9013 for ; Sat, 2 Jan 2021 17:52:37 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (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 "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7Txb6nhTz4jSn for ; Sat, 2 Jan 2021 17:52:35 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sat, 02 Jan 2021 17:52:25 +0000 To: =?utf-8?Q?Klaus_K=C3=BCchemann?= , Andy McClements , freebsd-arm@freebsd.org From: Robert Crowston Reply-To: Robert Crowston Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? Message-ID: <09BhpOupVkw74fRiKpOND2bd4r7Vk00-n85QKhMlDgYK41btZ-hZUFpYlKYFJg1k6vKoR6ChEwFoK0FK3EhnKnzlYslmMIt1aP2CPjOkVlQ=@protonmail.com> In-Reply-To: <5B626DCC-6F7C-4554-803C-F488A1ED9BEB@googlemail.com> References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> <5B626DCC-6F7C-4554-803C-F488A1ED9BEB@googlemail.com> MIME-Version: 1.0 X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4D7Txb6nhTz4jSn X-Spamd-Bar: / X-Spamd-Result: default: False [0.10 / 15.00]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; DKIM_TRACE(0.00)[protonmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; FREEMAIL_TO(0.00)[googlemail.com,ip-ether.net,freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[185.70.40.134:from]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[185.70.40.134:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; AUTOGEN_PHP_SPAMMY(1.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.134:from]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 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: Sat, 02 Jan 2021 17:52:37 -0000 VGhhbmtzIGJvdGguCgpLbGF1cywgd2Ugc2hvdWxkIGxpc3RlbiB0byB5b3UgbW9yZSBvZnRlbiA6 LSkKCuKAlCBSSEMuCgpPbiBTYXQsIEphbiAyLCAyMDIxIGF0IDE3OjUxLCBLbGF1cyBLw7xjaGVt YW5uIHZpYSBmcmVlYnNkLWFybSA8ZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmc+IHdyb3RlOgoKPj4g QW0gMDIuMDEuMjAyMSB1bSAxODozNSBzY2hyaWViIEFuZHkgTWNDbGVtZW50cyA8YWptQGlwLWV0 aGVyLm5ldD46Cj4+Cj4+IHdhcyBhY3R1YWxseSBib290aW5nIGZyb20gdGhlIFNTRCB3aXRoIG5v IFNEIGNhcmQgcHJlc2VudCwgdGhpcyBjYXVzZWQgYSBjcmFzaCBpbiBVLWJvb3QuCj4+Cj4gSGks Cj4KPiB0aGFua3MgZm9yIHRlc3RpbmcgISAuLmFuZCBwbGVhc2VkIHRvIGhlYXIgdGhhdCB3ZSBo YXZlIG1hZGUgcHJvZ3Jlc3Mg4oCmCj4gdGhlcmUgc2VlbXMgdG8gYmUgc29tZXRoaW5nIGdvaW4g d3Jvbmcgd2l0aCBvdXIgcmVsZWFzZSB3aGljaCBkb2VzbuKAmXQgZW1iZWQgdGhlIHJwaS1maXJt d2FyZSBjb3JyZWN0bHkKPiBJbiB0aGUgcnBpLXJlbGVhc2XigKYKPiBDb3VsZCB5b3UgcGxlYXNl IHRlc3QgYnkgb3ZlcndyaXRpbmcgdGhlIGZvbGxvd2luZyBmaWxlcyB0byB0aGUgbXNkb3MgLSBw YXJ0aXRpb24gOgo+IGh0dHBzOi8vZ2l0aHViLmNvbS9yYXNwYmVycnlwaS9maXJtd2FyZS9ibG9i L21hc3Rlci9ib290L2JjbTI3MTEtcnBpLTQtYi5kdGIKPiBodHRwczovL2dpdGh1Yi5jb20vcmFz cGJlcnJ5cGkvZmlybXdhcmUvYmxvYi9tYXN0ZXIvYm9vdC9zdGFydDQuZWxmCj4gaHR0cHM6Ly9n aXRodWIuY29tL3Jhc3BiZXJyeXBpL2Zpcm13YXJlL2Jsb2IvbWFzdGVyL2Jvb3QvZml4dXA0LmRh dAo+Cj4gb3IgYmV0dGVyIHdpdGggYWxsIGZpbGVzIHdoaWNoIGhhdmUgdGhlIG51bWJlciA0IGlu IGl0IGluIDoKPiBodHRwczovL2dpdGh1Yi5jb20vcmFzcGJlcnJ5cGkvZmlybXdhcmUvdHJlZS9t YXN0ZXIvYm9vdAo+Cj4gVGhhdCBzaG91bGQgZml4IHRoZSBTRC1jYXJkLXRoaW5nIGJlY2F1c2Ug SSBndWVzcyB0aGUgZHRiLWZpeCBtYWRlIGl0IHVwc3RyZWFtIG1lYW53aGlsZSwKPiBJZiBub3Qg d2Ugd2lsbCBjb250aW51ZSBoYWNraW5nIHRoYXQuLi4KPgo+IFRoYW5rcyBpbiBhZHZhbmNlCj4K PiBSZWdhcmRzCj4KPiBLLgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KPiBmcmVlYnNkLWFybUBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKPiBodHRw czovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1hcm0KPiBUbyB1 bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1hcm0tdW5zdWJzY3JpYmVAZnJl ZWJzZC5vcmci From owner-freebsd-arm@freebsd.org Sat Jan 2 18:08: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 3D9834D953D for ; Sat, 2 Jan 2021 18:08:05 +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 4D7VHS0VQwz4jw0 for ; Sat, 2 Jan 2021 18:08:03 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x32e.google.com with SMTP id c133so13417136wme.4 for ; Sat, 02 Jan 2021 10:08:03 -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=CmGX1TAyjRiK/NZalS0vUXWnY4sr9W7xJspWZUsL25k=; b=QOaN0xboy7Ca1hBJjRePyJNbiztX4kCj9gjvo7tu55BZOMuRKvsVwFWokDMzxQVu/o gcsSRvBubvWT4u5HCG+ww+eNXupfq+soPddaZFmPxKZ7ds98hNMCV818L5oyBsOmTqev FkSB3pVP83PtdwKecVjLup34hcBrEvRkW31T6nxvmIu5zaqrz0N+ILVXJMlqnULFpma+ tWR/vkM2vwZ1dWyiEDYLPeLfcWiS0H0DdcFAKft7otijACCo7OHymv2RlJZW/HpGiAGY SszT7P3XXi0Y/8v8eC7QBsJhPZTahY74anikjS+VHei+3S2GZzHftLaPpNwE/6uUbo/i MkIQ== X-Gm-Message-State: AOAM5336JictTN99px551TGFSjQcynQXoCgFigANarzGp0qbh8vQCrI1 ssAvgNHlZuZGWYFYOzmBh/o= X-Google-Smtp-Source: ABdhPJzk+ibeZlHVZGNoINjtj3Je98Md2KGOIAgiZ3ijkzoj/Oi9UOvHJPxCa2MiVpD2mlMwx7Dxyw== X-Received: by 2002:a1c:4c07:: with SMTP id z7mr20120966wmf.142.1609610882086; Sat, 02 Jan 2021 10:08:02 -0800 (PST) Received: from [192.168.1.167] (dynamic-046-114-106-160.46.114.pool.telefonica.de. [46.114.106.160]) by smtp.googlemail.com with ESMTPSA id q73sm27178449wme.44.2021.01.02.10.08.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Jan 2021 10:08:01 -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: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? Date: Sat, 2 Jan 2021 19:07:59 +0100 References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> <5B626DCC-6F7C-4554-803C-F488A1ED9BEB@googlemail.com> <09BhpOupVkw74fRiKpOND2bd4r7Vk00-n85QKhMlDgYK41btZ-hZUFpYlKYFJg1k6vKoR6ChEwFoK0FK3EhnKnzlYslmMIt1aP2CPjOkVlQ=@protonmail.com> To: Robert Crowston , freebsd-arm@freebsd.org In-Reply-To: <09BhpOupVkw74fRiKpOND2bd4r7Vk00-n85QKhMlDgYK41btZ-hZUFpYlKYFJg1k6vKoR6ChEwFoK0FK3EhnKnzlYslmMIt1aP2CPjOkVlQ=@protonmail.com> Message-Id: <593E18B2-A45E-4770-870C-18C00C9D9DA1@googlemail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D7VHS0VQwz4jw0 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)[-0.997]; FREEMAIL_TO(0.00)[protonmail.com,freebsd.org]; 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.106.160: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::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: Sat, 02 Jan 2021 18:08:05 -0000 > Am 02.01.2021 um 18:52 schrieb Robert Crowston = : >=20 > Thanks both. >=20 > Klaus, we should listen to you more often :-) >=20 > =E2=80=94 RHC.=20 >=20 you always listened to me, thank you! ;-) but the most I would love is = to listen TO YOU if you would publish one of your special jtag-sessions = ;-) yeah,! your setup works quite good: = https://www.raspberrypi.org/forums/viewtopic.php?t=3D254142#p1674662 Regards K.= From owner-freebsd-arm@freebsd.org Sat Jan 2 18:39:25 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 B81DF4DA731 for ; Sat, 2 Jan 2021 18:39:25 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7Vzd0hz2z4m4P for ; Sat, 2 Jan 2021 18:39:24 +0000 (UTC) (envelope-from ajm@ip-ether.net) Received: from [5.83.10.113] (port=57799 helo=[10.0.30.30]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92.3) (envelope-from ) id 1kvlo6-0004u6-3o; Sat, 02 Jan 2021 18:39:22 +0000 Subject: Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? To: =?UTF-8?Q?Klaus_K=c3=bcchemann?= References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> <5B626DCC-6F7C-4554-803C-F488A1ED9BEB@googlemail.com> From: Andy McClements Cc: freebsd-arm Message-ID: <56d10ea4-3284-3e4c-9521-8bf1008caa2b@ip-ether.net> Date: Sat, 2 Jan 2021 18:39:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <5B626DCC-6F7C-4554-803C-F488A1ED9BEB@googlemail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BlackCat-Spam-Score: 9 X-Spam-Status: No, score=0.9 X-Rspamd-Queue-Id: 4D7Vzd0hz2z4m4P X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ajm@ip-ether.net designates 2a00:1098:0:82:1000:0:2:1 as permitted sender) smtp.mailfrom=ajm@ip-ether.net X-Spamd-Result: default: False [-2.36 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1098:0:82:1000:0:2:1:from]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1098::82:1000:0:2:1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ip-ether.net]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[2a00:1098:0:82:1000:0:2:1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[2a00:1098:0:82:1000:0:2:1:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.86)[-0.856]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:2a00:1098::/32, country:GB]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] 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, 02 Jan 2021 18:39:25 -0000 On 02/01/2021 17:51, Klaus Küchemann wrote: >> was actually booting from the SSD with no SD card present, this caused a crash in U-boot. >> > Hi, > > thanks for testing ! ..and pleased to hear that we have made progress … > there seems to be something goin wrong with our release which doesn’t embed the rpi-firmware correctly > In the rpi-release… > Could you please test by overwriting the following files to the msdos - partition : > https://github.com/raspberrypi/firmware/blob/master/boot/bcm2711-rpi-4-b.dtb > https://github.com/raspberrypi/firmware/blob/master/boot/start4.elf > https://github.com/raspberrypi/firmware/blob/master/boot/fixup4.dat > > or better with all files which have the number 4 in it in : > https://github.com/raspberrypi/firmware/tree/master/boot > > That should fix the SD-card-thing because I guess the dtb-fix made it upstream meanwhile, > If not we will continue hacking that... Hi Klaus, I have been using firmware files datestamped 27/12/2020 6:14, from: https://github.com/raspberrypi/firmware/archive/master.zip I have used these, to replace ALL those files on the DOS partition in the 20201224 img. I had assumed these were all the 'latest' versions. I just did a 'fc' of a file from the ZIP file, against one downloaded from your links above: D:\RPi4b\RPI_Firmware>fc blob-master_dtb\bcm2711-rpi-4-b.dtb master\boot\bcm2711-rpi-4-b.dtb Comparing files BLOB-MASTER_DTB\bcm2711-rpi-4-b.dtb and MASTER\BOOT\BCM2711-RPI-4-B.DTB FC: no differences encountered So I am reasonably confident I have indeed been using the correct latest versions. I am happy to do any further testing, or checking on my tests if you feel they may have been in error. From owner-freebsd-arm@freebsd.org Sat Jan 2 19:39:31 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 F218E4DC7CF for ; Sat, 2 Jan 2021 19:39:31 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 4D7XJz0r3Fz4rMX; Sat, 2 Jan 2021 19:39:30 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x42c.google.com with SMTP id d13so26955135wrc.13; Sat, 02 Jan 2021 11:39:30 -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=vivAaGQoA1+ISG4JMWbk32PCqZ3pmeqfu18Q4gx+BNU=; b=R79OwrvH1pOPx/YRbKxjbwUldkQPsxFrNx/p6oKjQE3tUKPFy27gyvbLlRBQLNlnGr nTm+WRToKdS/00JEAK9SOkh+alChgxMitlwh1JOFwvBvTJHK4bt+KrNG1pEvPdVyU+Af j9AhnXoyeeaNyKPUTYOlHEZlVsvj67b9r+CzRGn31su1wgRtR+jYJTP0/eezG5+0AncQ wCmiH4PoBzp3kLrAxB/pnqo+S1Okyx/FvmzH3I/Wd1DSfFTWtEg261+4wXMbQRY7Jnop Pn7zr4sgifawswpyLQrJT3ydVzsGjCnjPvVCRFD6B0dRQK9qJpvPA6Vp8gU6j6MXBdD4 /TYg== X-Gm-Message-State: AOAM533Jlu6n66fVawrLgIxiVMwCN2O5naiDF2zl8pWh9LA3EjAA5q8x 3++QYl8sfS9cWaVrQMZDNSP27ClL99I1dA== X-Google-Smtp-Source: ABdhPJx5yaecHVEA08hFB0s2UX01MVk2GowNEYeCV7xZxuAhzvsc9CafymdHA9QaH3d2ZIek1bsKPQ== X-Received: by 2002:a05:6000:90:: with SMTP id m16mr73863348wrx.165.1609616369927; Sat, 02 Jan 2021 11:39:29 -0800 (PST) Received: from [192.168.1.167] (dynamic-046-114-106-160.46.114.pool.telefonica.de. [46.114.106.160]) by smtp.googlemail.com with ESMTPSA id a25sm24114223wmb.25.2021.01.02.11.39.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Jan 2021 11:39:29 -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: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ? Date: Sat, 2 Jan 2021 20:39:27 +0100 References: <007c8658-b7b6-6852-536c-9c36af64506b@ip-ether.net> <5B626DCC-6F7C-4554-803C-F488A1ED9BEB@googlemail.com> <56d10ea4-3284-3e4c-9521-8bf1008caa2b@ip-ether.net> To: Andy McClements , freebsd-arm@freebsd.org, Robert Crowston , Emmanuel Vadot In-Reply-To: <56d10ea4-3284-3e4c-9521-8bf1008caa2b@ip-ether.net> Message-Id: <26D146B8-0362-4008-9A1F-A6CD6B1479BB@googlemail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D7XJz0r3Fz4rMX 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:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; FREEMAIL_TO(0.00)[ip-ether.net,freebsd.org,protonmail.com]; 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::42c: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.106.160:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::42c:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c: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: Sat, 02 Jan 2021 19:39:32 -0000 > Am 02.01.2021 um 19:39 schrieb Andy McClements : >=20 > Hi Klaus, >=20 > I have been using firmware files datestamped 27/12/2020 6:14, from: > =E2=80=A6. >=20 > I am happy to do any further testing, or checking on my tests if you = feel they may have been in error. >=20 >=20 thanks a lot, I could reproduce the issue you have with their firmware files datestamped 27/12/2020 , it seems that they have mixed up something=20 @ the rpi-org since I`ve got the following files from them earlier... Could you please overwrite on msdos-partition with these files : = https://sourceforge.net/projects/d26853-bcm2711-rpi-4-b-dtb/files/rpi4_pac= k_freebsd.zip/download I=E2=80=99m quite sure, that this will fix the SD-card-issue , So it should boot directly from USB/SSD. You can begin with only : start4.elf & fixup4.dat , If that doesn`t work you can also apply u-boot.bin. If this not succeeds, we will have to think about different silicon on = different rpi-models but I guess it will work. Thanks in advance ! Regards K.=