Re: PR 252541: Early kernel panic on RPi4B (Too many early devmatch mappings)

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üchemann <maciphone2 at googlemail.com> wrote:
>>>> Am 12.01.2021 um 07:42 schrieb Mark Millard via freebsd-arm <[email protected]>:
>>>> 
>>>> Also, my context was a amd64->aarch64 cross-build
>>>> instead of being an aarch64 native build.…….src.conf like file, make.conf …...
>>> 
>>> I have compiled directly on the RPI with nonexistent src.conf/make.conf & standard kernconfs,
>>> no problems .
>> 
>> Good to know what you used for such files and the build machine.
>> 
>> 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.)
>> 
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>> ( dsl-only.net went
>> away in early 2018-Mar)
> 
> Hi Mark,
> 
> 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=1
> WITH_EXTRA_TCP_STACKS=1
> WITH_BEARSSL=1
> WITH_PIE=1
> WITH_RETPOLINE=1
> WITHOUT_CLEAN=1
> ---------------------------

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.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"