Date: Tue, 12 Jan 2021 10:25:45 +0100 From: Andrea Brancatelli <abrancatelli@schema31.it> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: freebsd-arm@freebsd.org Subject: Re: Updates on 13-STABLE on Apple M1 (Parallel Desktop) Message-ID: <5aa06fb811680281b48561898c50e070@schema31.it> In-Reply-To: <202101112039.10BKdIt3034149@gndrsh.dnsmgr.net> References: <202101112039.10BKdIt3034149@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-01-11 21:39, Rodney W. Grimes wrote: >> root@f13:~ # uname -a >> FreeBSD f13 13.0-CURRENT FreeBSD 13.0-CURRENT #0 > ^^^^^^^^^^^^^^^^ > > FYI, there is no such thing as 13-STABLE at this time, it is 13-CURRENT. You're absolutely right, my wrong. Yet, if there's anything I can try to make it behave better, it would be cool :-) From owner-freebsd-arm@freebsd.org Tue Jan 12 09:29:08 2021 Return-Path: <owner-freebsd-arm@freebsd.org> 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 137484D00B8 for <freebsd-arm@mailman.nyi.freebsd.org>; Tue, 12 Jan 2021 09:29:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-19.consmr.mail.gq1.yahoo.com (sonic313-19.consmr.mail.gq1.yahoo.com [98.137.65.82]) (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 4DFQJ35ShHz4fhS for <freebsd-arm@freebsd.org>; Tue, 12 Jan 2021 09:29:07 +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=1610443745; bh=VkcG42+dQA5UvZNQjQyZ7qd/zVgtlE0QK/uEiNSETdy=; h=Subject:From:Date:To:From:Subject:Reply-To; b=Lwirkvm27w1r7+/BKR+sb3NEjDqR3Nf5Yc7iYQRJv8l79SAeM+Tfljcajz5FXJDrNZykwIZ5C/TddlEyy0eH7CWLqGm8d0Dm81WkZ3i+rUSNeLClxYLzBJH5aihCXtrrW7FAflJkYonorOaV21S/Tfkq7bri4+tAY6RE0RvRlPut8pPd1cwd4642dGZplhesV1QUAuyajlqEvnRDNFKU2CPLSOgqvrK29VDjAQ93khHHIfAbgWS9F4FNtr00t1V1Xb4onGCUlPiuM9rpvQI3oNMzSiSI7wobyKA1emNwjcAxgQE22grkUlgZg4u7yMFX77PXw1bGMzvlWWCnr7zmLg== X-YMail-OSG: V5BcsmwVM1nZ2SgFjA7PqeI35SLJTOgjUdkwbxFvX2DEzaHSCDJYEyv783rAK6K 7vVcw128QrkTDbbRvxap68nxL49EzQCUcJUkNoeN7lLtd5B8BwvzLMHB4mhONxNUzQOArudSglR. QYLuSNTCmlLqId48c2XUFT3zgnfDt.0RfsGPi_7WRbCYWB1kXVmxz20HJ6CmcKCY8RV16bRcbrUu YMlJx92C41LQOx7HE8H1163yq9cIpVQkAWP.eF9.hBdPIkXezobMUR1DJmhAT3Sj0N8GrZ0WFcpe LYh96RsSKfQ4pF.Kj6KF_RNdJfh8gEWzoooPChj995ZyDHB3u9Q8RY6EHvNWlXgxHesYRo1uuRvt NQNMSOdzEfA__ptYMunZ4c8VrkE.RH1WcsnCfGAf_gdiOOFJ2rGK0O2VY4ts1S8pG1j6yi_yy.Mg bNvoYc3Jqnct1BhyS6pwtTOSID5YAKzKuObHJ8hLvW1nyP.J6f2StqFnXcJvGrpBjx4r72X9TKIa wED6O.Mh_srawsKZ97eH4f7xBNmWXKdsni6PTVzD5qeAMsmpKwv.nllUmyCa_B8DgzyrgI6bcsnX kL5rcqb6UYJNxlwHMZRF45EY7NxGFri36Qtz3cDKuI0Xxim7UEz5.gZZNJeDztKLO6oZw_V2pYR1 KK_kKbiV72piCqclbBT0NaZLvH.SBgRBWqWlY1V69JJe2YgNIU49SVGlSPlngmWpReGChjpwHSOI Wd8ZJhFE7XxUikWwF.xrVmD75iyISSV4r8vD7rdOR.rd5b0IN.lGTfUT1c7g.ve4Mjah6LNWkzZz aZyfszAU6tFuTb5U9vLWPWhr5a1ego7l8j4XiOQemkMLwT3doDqK5fmHoQ3nKSN84OAClY..sWX. sn3kiLEYg3Ez5q1T0bzDpH.xjcGJEEhs6ObDCmYQDgL_asRTCfq.2C7Hv6Z4ViE2avPy203tfbNf bg6PbAIkg5DzdacQvqV5yYaavKc_A542DnFcctRwtp7Bg.4S0EcB2npuv45sKq_oTRsJ3FgEgzhc JkXYzP3k04GqUvvfolqD2Lu9fRqAEhTDRvd_zf_DIsIR0A_SPbfvn3z8fmQqpJY5zX9Qi7laqecD Hgq8EzksNSXBEyCjYNpibIORb48WcwBv07kbqvmT6Z1MVrTwzHe5uzD6P19BG8LApbbRpcs33w_3 AEVFuAu4fu7CeyN8RPRyMYSUAOynUvx8Ol3TNDp3n2QxVErXyUuXyNvx36XOSa1R4VrIH_MGDXoV 1M6U1Q4ysckrhjR.UELrHOo26Jm7t2OJOFuDqf6r.Jjv4wWjt4ixG8KmyD6uiVgunD_WANBFCVdg I8rVG3g2Ff8MKkyuaKpcozovPi9QJBp7bMflm5W2uPGENDnfw5nv0mvqfie2shlYO.CDQ5AECLE4 9phXz_NGBo6AdmIgnkDZ2gfJACynEBoK1h.GcgEKoEnXLN3YZamtHLf75hJxnnjN1yvCZnO.VuVz C8I2BcQZnKf8EokEPi0YBH5.wvyZ1j38rJT9V96x1s0ZXYIKOaIE2Z2XPGsgzaD7POch5rHqmew1 AuSbwZXvkj09wguUFmXuBsZGxxW.NvK.DfqXAhFs8V.4aCIRiut9ApeSb_JWnmF9PmJ.XzogO8bg Mnht10R1av2XTSZAZizHwQfWUT_JFWEwefLfpiHgo2IbWEU_FhOpa3VHR9o75jCzEnjMlgVqBRd6 iusa3N5pcWS.6xPlPkD8W9YW7CacJm4IwJ8DYnfOM_o361Mb5OoHvfwOVc2ULy_BRU4M88MiT2HD 9fezcrk7GGFxMmO7Bv1_BH749dxZQO3uK6n9cpu..bSAoTXyc8C6JAIC2dMe9pCduCGQMEEr3mzz 90wVriUTsfirnGU545UxJjeTSLIS_OJoUFGzhpKNiiRIkO0mZy44krEhy._zBN6RCNKJqT3TEFL4 TTqoYELBWjPP3_ffsubm0NLQR.qe2mWsfbLf0OIrmWyIDoMC_oPambToANRp_66kZ6SRN62NszHu dtT2BLdEj6XZ077gMd4weKjGvfwYqFEeSJ5UgtT.0bs14uUfi2t1qARkTDrXMUhbsSJsn4GEkcIR 0Pop6gsX2zW9n0ugZKTtnMaWtkb_Wi5WWmOEJSMLVxKbNDZhZPRgoVv_c9C1HGcM116N0oUW6Mlg YsKHSXMvkQbt3iefPVg8axPlSbNBupF9Q4Lpq.UokaeU4ruUCIayvuxhwdhyvjmc_GKSv5qA9dkC Z_FE0qHHfTdnmocDy.uFUTFsOAjkfP.Awhu_fdq9p5B.RT8ig.SBHkL_VVfDD4fd7F_iDHvIkjZj DGfMqROmNffesBtfbNH4w_VhW8FNdNECia_JyfkmV0L66V64ZpQL4I19ltxnMvaLSg9pBDQHqCng Vh8AKDjPJ.kjSZge8vI3EKVKUYrq7Hgq9fln8zx3DQIjd1CNgbwlX5lfHyEKu8Szj0EfokBQo0H9 XFtH5jUoJ7OJGgDW1AglCvEfcb9wgAA5x2jxTofM5YRf8mpDSGVn__XiesZQmD6CqCTfsRLna571 X5pa7ZkWop2q0aL9EMUnm19MwSYA_5lFL0I_oxeO3t50kd9LY7DaCZG8ntx64WS.C6jq0ITZHecG G Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 12 Jan 2021 09:29:05 +0000 Received: by smtp407.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fa504da371c1957ebe5e13d5289fe854; Tue, 12 Jan 2021 09:29:03 +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: PR 252541: Early kernel panic on RPi4B (Too many early devmatch mappings) From: Mark Millard <marklmi@yahoo.com> In-Reply-To: <X/1f/sj5LuKh//o6@lion.0xfce3.net> Date: Tue, 12 Jan 2021 01:29:01 -0800 Cc: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com>, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <E3ABC40A-92FF-45B7-BB6E-B05AF930DC33@yahoo.com> References: <X/y5YbRUMOyn4Hwl@lion.0xfce3.net> <7C6DC946-B7B6-42C8-A8B9-0471ED7B77AA@yahoo.com> <F0031010-EBB0-4DDE-B9D1-20A0F161E4EA@yahoo.com> <784263FD-D17C-4CA5-991E-FE93E3E584F3@yahoo.com> <7655A4A0-B74E-41B5-8E93-8F39CD462A81@yahoo.com> <4CFBA50F-0C76-48A4-8D88-58ED76D4E444@googlemail.com> <8AA272E7-DC58-4129-B376-0BB663B63BA7@yahoo.com> <X/1f/sj5LuKh//o6@lion.0xfce3.net> To: Gordon Bergling <gbe@freebsd.org> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DFQJ35ShHz4fhS 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." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 12 Jan 2021 09:29:08 -0000 On 2021-Jan-12, at 00:38, Gordon Bergling <gbe at freebsd.org> wrote: > On Tue, Jan 12, 2021 at 12:16:30AM -0800, Mark Millard via freebsd-arm = wrote: >> On 2021-Jan-11, at 23:13, Klaus K=C3=BCchemann <maciphone2 at = googlemail.com> wrote: >>>> Am 12.01.2021 um 07:42 schrieb Mark Millard via freebsd-arm = <freebsd-arm@freebsd.org>: >>>>=20 >>>> Also, my context was a amd64->aarch64 cross-build >>>> instead of being an aarch64 native build.=E2=80=A6=E2=80=A6.src.conf = like file, make.conf =E2=80=A6... >>>=20 >>> I have compiled directly on the RPI with nonexistent = src.conf/make.conf & standard kernconfs, >>> no problems . >>=20 >> Good to know what you used for such files and the build machine. >>=20 >> We do not have builds of the same source version yet. I will not >> get to it tonight, but I will hopefully later try to build the >> version that you identified and see what I get for different >> variations in how to build that source version to produce debug >> kernel builds. (I might include the two printf's that report >> the figures that the KASSERT is based on.) >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) >=20 > Hi Mark, >=20 > thanks for your work on that issue. I have some spare time today and = will try some combinations > about NO INVARIANTS and so on. My src.conf is the following, For non-_STANDALONE contexts . . . KASSERT's only turn into do-something code when INVARIANTS is in use in the kernel build: #if defined(INVARIANTS) || defined(_STANDALONE) #define KASSERT(exp,msg) do { = \ if (__predict_false(!(exp))) = \ kassert_panic msg; = \ } while (0) #else /* !INVARIANTS && !_STANDALONE */ #define KASSERT(exp,msg) do { \ } while (0) #endif /* INVARIANTS || _STANDALONE */ But even when INVARIANTS is in use, there is a way to make KASSERT's report but not panic: KASSERT_PANIC_OPTIONAL and the resulting kassert_panic definition: #if defined(_STANDALONE) struct ucred; /* * Until we have more experience with KASSERTS that are called * from the boot loader, they are off. The bootloader does this * a little differently than the kernel (we just call printf atm). * we avoid most of the common functions in the boot loader, so * declare printf() here too. */ int printf(const char *, ...) __printflike(1, 2); # define kassert_panic printf #else /* !_STANDALONE */ # if defined(WITNESS) || defined(INVARIANT_SUPPORT) # ifdef KASSERT_PANIC_OPTIONAL void kassert_panic(const char *fmt, ...) __printflike(1, 2); # else # define kassert_panic panic # endif /* KASSERT_PANIC_OPTIONAL */ # endif /* defined(WITNESS) || defined(INVARIANT_SUPPORT) */ #endif /* _STANDALONE */ But I've no clue what all might be broken when the issue does not panic. (So: true of my non-debug builds.) > --------------------------- > WITH_MALLOC_PRODUCTION=3D1 > WITH_EXTRA_TCP_STACKS=3D1 > WITH_BEARSSL=3D1 > WITH_PIE=3D1 > WITH_RETPOLINE=3D1 > WITHOUT_CLEAN=3D1 > --------------------------- The WITHOUT_CLEAN can lead to oddities. It might be worth a from-scratch build to see if it gets the same result. I happened to have started from an empty build tree because because I do not normally keep a debug kernel build tree around. So my WITH_META_MODE in teh build script should not have made a difference. > I know that the change itselfs doesn't seems to be significant, but it = was the > first that has triggered the panic. Maybe it is also the u-boot.bin, I = haven't > updated them since the July. u-boot and the loader have both finished and the kernel is starting from what I've seen. So if u-boot or the loader is involved, it is via data left over after they finished. > I'll keep you posted. Thanks. Me too. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5aa06fb811680281b48561898c50e070>