Date: Tue, 12 Jan 2021 16:24:32 -0800 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: panic: Too many early devmap mappings Message-ID: <20210113002432.GA79600@www.zefox.net> In-Reply-To: <90C90797-A8A5-457C-AF07-800EA82F5F12@yahoo.com> References: <20210112233607.GA79348@www.zefox.net> <90C90797-A8A5-457C-AF07-800EA82F5F12@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 12, 2021 at 03:59:44PM -0800, Mark Millard wrote:
>
>
> On 2021-Jan-12, at 15:49, bob prohaska <fbsd at www.zefox.net> wrote:
>
> > An RPi3 running -current updated on Jan. 10 installed a new world/kernel and
> > when rebooted promptly crashed with
> >
> > ---<<BOOT>>---
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210113002432.GA79600>