From owner-freebsd-arm@freebsd.org Wed Jan 13 00:24:31 2021 Return-Path: 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 D52614EB16C for ; Wed, 13 Jan 2021 00:24:31 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFp9C08gJz4tJv for ; Wed, 13 Jan 2021 00:24:30 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 10D0OW40079752 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 Jan 2021 16:24:32 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 10D0OWoV079751; Tue, 12 Jan 2021 16:24:32 -0800 (PST) (envelope-from fbsd) Date: Tue, 12 Jan 2021 16:24:32 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: panic: Too many early devmap mappings Message-ID: <20210113002432.GA79600@www.zefox.net> References: <20210112233607.GA79348@www.zefox.net> <90C90797-A8A5-457C-AF07-800EA82F5F12@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90C90797-A8A5-457C-AF07-800EA82F5F12@yahoo.com> X-Rspamd-Queue-Id: 4DFp9C08gJz4tJv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.81 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.91)[0.911]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 00:24:31 -0000 On Tue, Jan 12, 2021 at 03:59:44PM -0800, Mark Millard wrote: > > > On 2021-Jan-12, at 15:49, bob prohaska wrote: > > > An RPi3 running -current updated on Jan. 10 installed a new world/kernel and > > when rebooted promptly crashed with > > > > ---<>--- > > panic: Too many early devmap mappings > > cpuid = 0 > > time = 1 > > KDB: stack backtrace: > > (null)() at 0xffff00000011ad90 > > pc = 0xffff000000760f70 lr = 0xffff00000011ad90 > > sp = 0xffff0000011df330 fp = 0xffff0000011df530 > > > > (null)() at 0xffff00000045c2d4 > > pc = 0xffff00000011ad90 lr = 0xffff00000045c2d4 > > sp = 0xffff0000011df540 fp = 0xffff0000011df5a0 > > > > (null)() at 0xffff00000045c07c > > pc = 0xffff00000045c2d4 lr = 0xffff00000045c07c > > sp = 0xffff0000011df5b0 fp = 0xffff0000011df660 > > > > (null)() at 0xffff0000007d8380 > > pc = 0xffff00000045c07c lr = 0xffff0000007d8380 > > sp = 0xffff0000011df670 fp = 0xffff0000011df670 > > > > (null)() at 0xffff00000075dc98 > > pc = 0xffff0000007d8380 lr = 0xffff00000075dc98 > > sp = 0xffff0000011df680 fp = 0xffff0000011df6a0 > > > > (null)() at 0xffff0000007710e4 > > pc = 0xffff00000075dc98 lr = 0xffff0000007710e4 > > sp = 0xffff0000011df6b0 fp = 0xffff0000011df6d0 > > > > (null)() at 0xffff00000028850c > > pc = 0xffff0000007710e4 lr = 0xffff00000028850c > > sp = 0xffff0000011df6e0 fp = 0xffff0000011df7a0 > > > > (null)() at 0xffff0000007c8788 > > pc = 0xffff00000028850c lr = 0xffff0000007c8788 > > sp = 0xffff0000011df7b0 fp = 0xffff0000011df830 > > > > (null)() at 0xffff00000028a64c > > pc = 0xffff0000007c8788 lr = 0xffff00000028a64c > > sp = 0xffff0000011df840 fp = 0xffff0000011df850 > > > > (null)() at 0xffff00000039b340 > > pc = 0xffff00000028a64c lr = 0xffff00000039b340 > > sp = 0xffff0000011df860 fp = 0xffff0000011df870 > > > > (null)() at 0xffff0000004a6950 > > pc = 0xffff00000039b340 lr = 0xffff0000004a6950 > > sp = 0xffff0000011df880 fp = 0xffff0000011df8b0 > > > > (null)() at 0xffff00000076d73c > > pc = 0xffff0000004a6950 lr = 0xffff00000076d73c > > sp = 0xffff0000011df8c0 fp = 0xffff0000011dfa00 > > > > (null)() at 0xffff00000000089c > > pc = 0xffff00000076d73c lr = 0xffff00000000089c > > sp = 0xffff0000011dfa10 fp = 0x0000000000000000 > > > > KDB: enter: panic > > [ thread pid 0 tid 0 ] > > Stopped at 0xffff0000004a6550 > > db> reboot > > cpu_reset failed > > > > It had to be power-cycled to restart. It came back up readily with > > kernel.old, which reports main-c255664-g4d64c7243d26 compiled Jan 9. > > > > In particular, how does one recognize which revision fixes > > this problem, assuming it's a bug and not operator error? > > Presumably, it'll take at least several days to reach git. > > Discovered last night on 8GiByte RPi4B's relative to this: > Booting without a monitor changes the memory use and avoids > the panic. WIth the 1920x1080 monitor it fails. (Only kernels > with INVARIANTS make the check that panics, but need not > mean that others are operating well, even if it is not > obvious in a specific context.) > > Quoted from part of a message list item from last night: > > QUOTE > Going back to my 19cca0b9613d based debug kernel build that > has the printf's reporting the values used in the test, but > with no monitor attached, it boots fine and reports: > > pmap_mapdev early_boot: akva_devmap_vaddr: ffff007ffffff000 size: 1000 > pmap_mapdev early_boot: va: ffff007fffffe000 VM_MAX_KERNEL_ADDRESS: ffff008000000000 L2_SIZE: 200000 > > That compares to the previously reported failure figures from > having the monitor attached for that debug kernel: > > pmap_mapdev early_boot: akva_devmap_vaddr: ffff007fff816000 size: 1000 > pmap_mapdev early_boot: va: ffff007fff815000 VM_MAX_KERNEL_ADDRESS: ffff008000000000 L2_SIZE: 200000 > panic: Too many early devmap mappings > > where the code does: > > KASSERT(va >= VM_MAX_KERNEL_ADDRESS - L2_SIZE, > ("Too many early devmap mappings")); > > > Looks like akva_devmap_vaddr gets smaller to make room above > for monitor related data and so va can end up being too small > by the criteria of this test. > > I've no clue who would be appropriate for dealing with this. > END QUOTE > > You may have provided a bound for a bisection > It looks as if unplugging the HDMI monitor (1920x1200) fixed the panic on the RPi3B+ as well. [the original subject line said "devmatch", which confused me hugely 8-)] Thanks for replying! bob prohaska