Re: PR 252541: Early kernel panic on RPi4B (Too many early devmatch mappings) [tied to monitor connected vs. not]
Mark Millard via freebsd-arm <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On 2021-Jan-13, at 16:31, tech-lists <tech-lists at zyxst.net> wrote: > On Tue, Jan 12, 2021 at 03:17:49AM -0800, Mark Millard via freebsd-arm wrote: >> Before the detailed sequence/evidence below: I eventually found how to >> control works vs. fails . . . >> >> Fails: have my monitor connected (1920 x 1080 in case it is important) >> Works: no monitor connected >> (Same kernel.) > > I have exactly the reverse situation: boots *only* with monitor attached. It would probably be best to submit a description of the context, the visible serial console output for the failure case, etc. in a message with its own subject. The context can include identifying what RPi firmware, what u-boot or UEFI/ACPI version, what FreeBSD version, debug vs. non-debug status for the parts of FreeBSD. It may involve reporting the steps to make the boot media used for the failing context as a way of identifying some of that. My testing did involve no-monitor-connected testing. That always worked, as did all non-debug kernels (so, INVARIANTS disabled). In the end, it turned out that early-kernel-memory allocations that totaled to be sufficiently large caused an incorrect KASSERT to fail in INVARIANTS aarch64 kernels. The correction has been committed to main. The allocations were not so large as to be an actual problem. === 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]"