Date: Wed, 13 Jan 2021 17:51:49 -0800 From: Mark Millard <marklmi@yahoo.com> To: tech-lists <tech-lists@zyxst.net> Cc: freebsd-arm@freebsd.org Subject: Re: panic: Too many early devmap mappings Message-ID: <5B791090-1597-4CC3-B469-502EF2130597@yahoo.com> In-Reply-To: <X/9lHxi2AZVdYIOY@bastion.zyxst.net> References: <20210112233607.GA79348@www.zefox.net> <90C90797-A8A5-457C-AF07-800EA82F5F12@yahoo.com> <20210113002432.GA79600@www.zefox.net> <04FEAC11-5603-4D4E-8651-43AB37A10B46@yahoo.com> <3C95F8C0-73FA-4DEC-9F0A-6FFF9846E8A3@yahoo.com> <X/9lHxi2AZVdYIOY@bastion.zyxst.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-13, at 13:24, tech-lists <tech-lists at zyxst.net> wrote: >=20 > On Tue, Jan 12, 2021 at 10:53:00PM -0800, Mark Millard via freebsd-arm = wrote: >=20 >> I forgot to list the bugzilla for this: >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252541 >>=20 >> I have added the notes, including: >>=20 >> QUOTE >> Turns out that this "too much high kernel memory in use" issue = happens for >> a combination of 2 things being true at the same time: >>=20 >> A) Monitor attached (sufficiently large pixel count?) >> B) GDB enabled, per bbfa199cbc16 . >> END QUOTE >=20 > Hi, >=20 > About a week ago, made new world on this rpi4b, installed it, rebooted > and it didn't come back. It normally runs headless, keyboardless. > If these are plugged in, the pi rebooted, it all comes back. [So my note from another subject was at least partially covered under this subject: here there are some details of the configuration.] [You may want your own subject for your issue(s), instead of using this mis-matching one.] Does it have a serial console set up? It likely needs to in order to be able to track down any such problems. As I use a serial console directly, I normally do not have a keyboard attached. A monitor being attached or not is mostly tied to testing boot environments (u-boot and UEFI/ACPI based). I normally otherwise ignore it when it is connected. I normally have a USB3 SSD connected and possibly a USB3 based EtherNet. (I helped with some testing of the EtherNet and left it in place.) I may or may not have a monitor connected at any point. No other connections at the RPi4B, no other media inserted. I do my own buildworld buildkernel and the like for normal operation. (artifacts.ci.free.org is still not being populated with snapshots for git's main. I tends to use these for testing official-build behavior when they are available.) > Same/similar problem? Context is main-c255784-ge83fdf8bb39. Its kernel > config file: >=20 > nooptions INVARIANTS > nooptions INVARIANT_SUPPORT > nooptions WITNESS > nooptions WITNESS_SKIPSPIN > nooptions DEADLKRES > nooptions USB_DEBUG > nooptions COVERAGE > nooptions KCOV > nooptions MALLOC_DEBUG_MAXZONES > options FUSEFS > device wlan # 802.11 support > device wlan_wep # 802.11 WEP support > device wlan_ccmp # 802.11 CCMP support > device wlan_tkip # 802.11 TKIP support > device wlan_amrr # AMRR transmit rate control = algorithm > device run # rpi supplied external usb2 wifi > device runfw # firmware >=20 e83fdf8bb39 is after where my normal environment is currently based. So I've no clue if something later then what I'm at would do similarly. Without the serial console output for your context, there is not much to work off of and no way to figure out how far it got before something odd happened. I've also no clue of the consequences of not having most of what is in a sys/arm64/conf/GENERIC* . I include a GENERIC* base and then list my kernel configs, such as: # more sys/arm64/conf/GENERIC-NODBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT=3D0 # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING =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?5B791090-1597-4CC3-B469-502EF2130597>