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. Thanks for reading, bob prohaska _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[hidden email]" |
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 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[hidden email]" |
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 _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[hidden email]" |
[I have a git bisect result for the failure: bbfa199cbc16.]
On 2021-Jan-12, at 16:24, bob prohaska <fbsd at www.zefox.net> wrote: > 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-)] > A git bisect sequence on a 8 GiBYte RPi4B with a monitor plugged in (to make it use more high kernel RAM such that the KASSERT indicated above fails) resulted in: # git bisect good bbfa199cbc1698631a0e932848e62dd76559d4d7 is the first bad commit commit bbfa199cbc1698631a0e932848e62dd76559d4d7 Author: mhorne <[hidden email]> Date: Wed Dec 9 16:38:42 2020 -0400 arm64: gdb(4) machine-dependent bits Everything required for remote kernel debugging over a serial connection. For FDT-based systems, a debug port can be specified by setting hw.fdt.dbgport to the desired device tree node in loader.conf. For example, hw.fdt.dbgport="uart1", or hw.fdt.dbgport="serial@ff1a0000". Looks good: emaste Tested by: rwatson MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D27727 sys/arm64/arm64/gdb_machdep.c | 112 ++++++++++++++++++++++++++++++++++++++++ sys/arm64/conf/GENERIC | 2 +- sys/arm64/include/gdb_machdep.h | 81 +++++++++++++++++++++++++++++ sys/conf/files.arm64 | 1 + 4 files changed, 195 insertions(+), 1 deletion(-) create mode 100644 sys/arm64/arm64/gdb_machdep.c create mode 100644 sys/arm64/include/gdb_machdep.h === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[hidden email]" |
On 2021-Jan-12, at 16:55, Mark Millard <marklmi at yahoo.com> wrote:
> [I have a git bisect result for the failure: bbfa199cbc16.] > > On 2021-Jan-12, at 16:24, bob prohaska <fbsd at www.zefox.net> wrote: > >> 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-)] >> > > A git bisect sequence on a 8 GiBYte RPi4B with a monitor plugged > in (to make it use more high kernel RAM such that the KASSERT > indicated above fails) resulted in: > > # git bisect good > bbfa199cbc1698631a0e932848e62dd76559d4d7 is the first bad commit > commit bbfa199cbc1698631a0e932848e62dd76559d4d7 > Author: mhorne <[hidden email]> > Date: Wed Dec 9 16:38:42 2020 -0400 > > arm64: gdb(4) machine-dependent bits > > Everything required for remote kernel debugging over a serial > connection. For FDT-based systems, a debug port can be specified by > setting hw.fdt.dbgport to the desired device tree node in loader.conf. > For example, hw.fdt.dbgport="uart1", or > hw.fdt.dbgport="serial@ff1a0000". > > Looks good: emaste > Tested by: rwatson > MFC after: 2 weeks > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D27727 > > sys/arm64/arm64/gdb_machdep.c | 112 ++++++++++++++++++++++++++++++++++++++++ > sys/arm64/conf/GENERIC | 2 +- > sys/arm64/include/gdb_machdep.h | 81 +++++++++++++++++++++++++++++ > sys/conf/files.arm64 | 1 + > 4 files changed, 195 insertions(+), 1 deletion(-) > create mode 100644 sys/arm64/arm64/gdb_machdep.c > create mode 100644 sys/arm64/include/gdb_machdep.h > I forgot to list the bugzilla for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252541 I have added the notes, including: 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: A) Monitor attached (sufficiently large pixel count?) B) GDB enabled, per bbfa199cbc16 . END QUOTE === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[hidden email]" |
On Tue, Jan 12, 2021 at 10:53:00PM -0800, Mark Millard wrote:
[trimmed for brevity] > On 2021-Jan-12, at 16:55, Mark Millard <marklmi at yahoo.com> wrote: > > > I forgot to list the bugzilla for this: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252541 > > I have added the notes, including: > > 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: > > A) Monitor attached (sufficiently large pixel count?) > B) GDB enabled, per bbfa199cbc16 . > END QUOTE > Just for fun I re-connected the monitor after the Pi3 had booted. It didn't work, which I _think_ is normal for a Pi booted without a monitor. The console reported: MESS:00:43:36.897488:0: hdmi: HDMI:>>>>>>>>>>>>>Rx sensed, reading EDID<<<<<<<<<<<<< MESS:00:43:36.915571:0: hdmi: HDMI:EDID version 1.3, 0 extensions, screen size 52x33 cm MESS:00:43:36.921928:0: hdmi: HDMI:EDID features - videodef 0x80 standby suspend active off; colour encoding:RGB444|YCbCr444|YCbCr422; sRGB is default colourspace; preferred format is native; does not support GTF MESS:00:43:36.940534:0: hdmi: HDMI:EDID found preferred DMT detail timing format: 1920x1200p @ 60 Hz (68) MESS:00:43:36.949773:0: hdmi: HDMI:EDID found DMT format: code 4, 640x480p @ 60 Hz in established timing I/II MESS:00:43:36.959407:0: hdmi: HDMI:EDID found DMT format: code 6, 640x480p @ 75 Hz in established timing I/II MESS:00:43:36.969044:0: hdmi: HDMI:EDID found DMT format: code 9, 800x600p @ 60 Hz in established timing I/II MESS:00:43:36.978682:0: hdmi: HDMI:EDID found DMT format: code 11, 800x600p @ 75 Hz in established timing I/II MESS:00:43:36.988408:0: hdmi: HDMI:EDID found DMT format: code 16, 1024x768p @ 60 Hz in established timing I/II MESS:00:43:36.998218:0: hdmi: HDMI:EDID found DMT format: code 18, 1024x768p @ 75 Hz in established timing I/II MESS:00:43:37.008032:0: hdmi: HDMI:EDID found DMT format: code 36, 1280x1024p @ 75 Hz in established timing I/II MESS:00:43:37.017975:0: hdmi: HDMI:EDID standard timings block x 8: 0x8180 A940 714F B300 0101 0101 0101 0101 MESS:00:43:37.027665:0: hdmi: HDMI:EDID found DMT format: code 35, 1280x1024p @ 60 Hz (5:4) in standard timing 0 MESS:00:43:37.037562:0: hdmi: HDMI:EDID found DMT format: code 51, 1600x1200p @ 60 Hz (4:3) in standard timing 1 MESS:00:43:37.047457:0: hdmi: HDMI:EDID found DMT format: code 21, 1152x864p @ 75 Hz (4:3) in standard timing 2 MESS:00:43:37.057272:0: hdmi: HDMI:EDID found DMT format: code 58, 1680x1050p @ 60 Hz (16:10) in standard timing 3 MESS:00:43:37.067327:0: hdmi: HDMI:EDID filtering formats with pixel clock > 162 MHz or h. blanking > 1023 MESS:00:43:37.076805:0: hdmi: HDMI:EDID preferred mode remained as DMT (68) 1920x1200p @ 60 Hz with pixel clock 154 MHz MESS:00:43:37.087189:0: hdmi: HDMI: hotplug attached with DVI support MESS:00:44:41.995274:0: hdmi: HDMI: hotplug deassert MESS:00:44:41.998532:0: hdmi: HDMI: HDMI is currently off MESS:00:44:42.003654:0: hdmi: HDMI: changing mode to unplugged Thanks for reading, bob prohaska _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by freebsd-arm mailing list
On Tue, Jan 12, 2021 at 10:53:00PM -0800, Mark Millard via freebsd-arm wrote:
>I forgot to list the bugzilla for this: > >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252541 > >I have added the notes, including: > >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: > >A) Monitor attached (sufficiently large pixel count?) >B) GDB enabled, per bbfa199cbc16 . >END QUOTE 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. Same/similar problem? Context is main-c255784-ge83fdf8bb39. Its kernel config file: 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 thanks, -- J. |
In reply to this post by freebsd-arm mailing list
On Wed, Jan 13, 2021 at 2:53 AM Mark Millard <[hidden email]> wrote:
> > On 2021-Jan-12, at 16:55, Mark Millard <marklmi at yahoo.com> wrote: > > > [I have a git bisect result for the failure: bbfa199cbc16.] > > > > On 2021-Jan-12, at 16:24, bob prohaska <fbsd at www.zefox.net> wrote: > > > >> 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-)] > >> > > > > A git bisect sequence on a 8 GiBYte RPi4B with a monitor plugged > > in (to make it use more high kernel RAM such that the KASSERT > > indicated above fails) resulted in: > > > > # git bisect good > > bbfa199cbc1698631a0e932848e62dd76559d4d7 is the first bad commit > > commit bbfa199cbc1698631a0e932848e62dd76559d4d7 > > Author: mhorne <[hidden email]> > > Date: Wed Dec 9 16:38:42 2020 -0400 > > > > arm64: gdb(4) machine-dependent bits > > > > Everything required for remote kernel debugging over a serial > > connection. For FDT-based systems, a debug port can be specified by > > setting hw.fdt.dbgport to the desired device tree node in loader.conf. > > For example, hw.fdt.dbgport="uart1", or > > hw.fdt.dbgport="serial@ff1a0000". > > > > Looks good: emaste > > Tested by: rwatson > > MFC after: 2 weeks > > Sponsored by: The FreeBSD Foundation > > Differential Revision: https://reviews.freebsd.org/D27727 > > > > sys/arm64/arm64/gdb_machdep.c | 112 ++++++++++++++++++++++++++++++++++++++++ > > sys/arm64/conf/GENERIC | 2 +- > > sys/arm64/include/gdb_machdep.h | 81 +++++++++++++++++++++++++++++ > > sys/conf/files.arm64 | 1 + > > 4 files changed, 195 insertions(+), 1 deletion(-) > > create mode 100644 sys/arm64/arm64/gdb_machdep.c > > create mode 100644 sys/arm64/include/gdb_machdep.h > > > > I forgot to list the bugzilla for this: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252541 > > I have added the notes, including: > > 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: > > A) Monitor attached (sufficiently large pixel count?) > B) GDB enabled, per bbfa199cbc16 . > END QUOTE > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > Hi all, The problem should be fixed with commit 818390ce0ca5 to main. Please let me know if you still encounter any issues after updating. Cheers, Mitchell _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by tech-lists
On 2021-Jan-13, at 13:24, tech-lists <tech-lists at zyxst.net> wrote: > > On Tue, Jan 12, 2021 at 10:53:00PM -0800, Mark Millard via freebsd-arm wrote: > >> I forgot to list the bugzilla for this: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252541 >> >> I have added the notes, including: >> >> 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: >> >> A) Monitor attached (sufficiently large pixel count?) >> B) GDB enabled, per bbfa199cbc16 . >> END QUOTE > > Hi, > > 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: > > 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 > 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=-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=0 # Enable verbose sysinit messages #options BOOTVERBOSE=1 #options BOOTHOWTO=RB_VERBOSE #options KTR #options KTR_MASK=KTR_TRAP ##options KTR_CPUMASK=0xF #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 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Mitchell Horne
On Wed, Jan 13, 2021 at 05:33:27PM -0400, Mitchell Horne wrote:
> > The problem should be fixed with commit 818390ce0ca5 to main. Please > let me know if you still encounter any issues after updating. > Just rebuilt the kernel, reboot was successful with monitor connected and also without. Thanks for reading, and your (and Mark's!) help. bob prohaska _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Mitchell Horne
On Wed, Jan 13, 2021 at 05:33:27PM -0400, Mitchell Horne wrote:
>Hi all, > >The problem should be fixed with commit 818390ce0ca5 to main. Please >let me know if you still encounter any issues after updating. Hi, The problem still happens with main-c255937-g818390ce0ca Is that before or after 818390ce0ca5 ? If after, I'll rebuild again. I use "git pull --ff-only" to update sources. If it still doesn't work, I'll build generic with no src.conf or make.conf. thanks, -- J. |
On Thu, Jan 14, 2021 at 9:29 AM tech-lists <[hidden email]> wrote:
> > On Wed, Jan 13, 2021 at 05:33:27PM -0400, Mitchell Horne wrote: > > >Hi all, > > > >The problem should be fixed with commit 818390ce0ca5 to main. Please > >let me know if you still encounter any issues after updating. > > Hi, > > The problem still happens with main-c255937-g818390ce0ca > Is that before or after 818390ce0ca5 ? > They are the same commit. I believe newvers.sh confusingly appends a 'g' to the git hash. Can you share information about your setup? What board you are using, monitor resolution, and console log would all be helpful information. If you could share this in the bug report that would be even better: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252541 Cheers, Mitchell > If after, I'll rebuild again. I use "git pull --ff-only" to update sources. > If it still doesn't work, I'll build generic with no src.conf or make.conf. > > thanks, > -- > J. _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by tech-lists
On 2021-Jan-14, at 05:29, tech-lists <[hidden email]> wrote: > On Wed, Jan 13, 2021 at 05:33:27PM -0400, Mitchell Horne wrote: > >> Hi all, >> >> The problem should be fixed with commit 818390ce0ca5 to main. Please >> let me know if you still encounter any issues after updating. > > Hi, > > The problem still happens with main-c255937-g818390ce0ca Is that before or after 818390ce0ca5 ? > > If after, I'll rebuild again. I use "git pull --ff-only" to update sources. > If it still doesn't work, I'll build generic with no src.conf or make.conf. You have been previously reporting a different problem on the lists, one with different symptoms. Are you now getting serial console reports of "Too many early devmap mappings"? Previously you reported: QUOTE 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. END QUOTE That is not the same problem as as fixed, from what I can tell from what you have reported. You have not reported any serial console output for when it fails for you. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Mitchell Horne
On Thu, Jan 14, 2021 at 03:11:29PM -0400, Mitchell Horne wrote:
>They are the same commit. I believe newvers.sh confusingly appends a >'g' to the git hash. >Can you share information about your setup? What board you are using, >monitor resolution, and console log would all be helpful information. >If you could share this in the bug report that would be even better: >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252541 Hi, The board is a raspberry pi 4 with 8GB, monitor resolution is 1920*1280. It is at the moment installing a new world, I'll update the bug report. thanks, -- J. |
In reply to this post by freebsd-arm mailing list
Hi,
On Thu, Jan 14, 2021 at 12:14:32PM -0800, Mark Millard wrote: >You have been previously reporting a different problem on the lists, >one with different symptoms. > >Are you now getting serial console reports of "Too many early devmap >mappings"? Previously you reported: > >QUOTE >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. >END QUOTE > >That is not the same problem as as fixed, from what I can tell >from what you have reported. You have not reported any serial >console output for when it fails for you. they both involve attaching HDMI and they both happened round the same time. I couldn't grab console output from that one at first as its housing blocks ttl access. Now I can, so if the issue persists I'll make a new bug report. -- J. |
Free forum by Nabble | Edit this page |