Skip site navigation (1)Skip section navigation (2)
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>