Date: Wed, 13 Jan 2021 17:10:36 -0800 From: Mark Millard <marklmi@yahoo.com> To: tech-lists <tech-lists@zyxst.net> Cc: freebsd-arm@freebsd.org Subject: Re: PR 252541: Early kernel panic on RPi4B (Too many early devmatch mappings) [tied to monitor connected vs. not] Message-ID: <A184BDB6-58FE-4997-A4C2-4B95CF37D905@yahoo.com> In-Reply-To: <X/%2BQ9k4o%2B5FXogj2@bastion.zyxst.net> References: <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> <E3ABC40A-92FF-45B7-BB6E-B05AF930DC33@yahoo.com> <7893EBCC-8431-4287-9F16-1AF28794F5CA@yahoo.com> <D8542CEB-EF9B-4FC3-AF7B-B7439225AD1A@yahoo.com> <X/%2BQ9k4o%2B5FXogj2@bastion.zyxst.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 . . . >>=20 >> Fails: have my monitor connected (1920 x 1080 in case it is = important) >> Works: no monitor connected >> (Same kernel.) >=20 > 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. =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?A184BDB6-58FE-4997-A4C2-4B95CF37D905>