Re: [14-CURRENT]BBB can't boot 14-CURRENT GENERICSD-20210805

Yoshiro MIHIRA <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <CALwmBx0zwfwDFDV_M-vM_8dnncL1wBi8FC+kagoKrLVPfrDFmA@mail.gmail.com>
If I manually build 14-CURRENT kernel(main-n248700-288e553623d3) and
replace /boot/kernel directory on  13.0-STABLE-arm-armv7-GENERICSD-20210812.
It can boot without panic.


2021年8月14日(土) 18:15 Yoshiro MIHIRA <[email protected]>:

> I can use 13.0-STABLE-arm-armv7-GENERICSD-20210812 on Beaglebone Black[OK].
>
> However, I tested 14-CURRENT GENERICSD-20210805 on Beaglebone Black.
> It can't boot with the below message[NG].
>
> Please let me know to solve this issue.
>
> If I use the same microSD on Raspberry PI2, it can boot without issue.
> I put all boot console messages.
> https://people.freebsd.org/~sanpei/20210814-boot-NG-14-GENERICSD-20210805
>
> <<BOOT message>
> mem: <memory>
> ofwbus0: <Open Firmware Device Tree>
> ti_sysc0: <TI SYSC Interconnect> on ofwbus0
> panic: Assertion size > 0 failed at /usr/src/sys/kern/subr_vmem.c:1332
> <----- PANIC!!
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
>          pc = 0xc05aa35c  lr = 0xc007ab68 (db_trace_self_wrapper+0x30)
>          sp = 0xc0e16a98  fp = 0xc0e16bb0
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>          pc = 0xc007ab68  lr = 0xc02d8ac0 (vpanic+0x17c)
>          sp = 0xc0e16bb8  fp = 0xc0e16bd8
>          r4 = 0x00000100  r5 = 0x00000000
>          r6 = 0xc06ff53d  r7 = 0xc08db4a8
> vpanic() at vpanic+0x17c
>          pc = 0xc02d8ac0  lr = 0xc02d8864 (doadump)
>          sp = 0xc0e16be0  fp = 0xc0e16be4
>          r4 = 0xc1e1b000  r5 = 0x00000000
>          r6 = 0x00000000  r7 = 0xc0e16c50
>          r8 = 0xc0b29d80  r9 = 0x00000002
>         r10 = 0xc0e16c2c
> doadump() at doadump
>          pc = 0xc02d8864  lr = 0xc0346514 (vmem_xalloc)
>          sp = 0xc0e16bec  fp = 0xc0e16c20
>          r4 = 0xc0e16c2c  r5 = 0xc0e16be4
>          r6 = 0xc02d8864 r10 = 0xc0e16bec
> vmem_xalloc() at vmem_xalloc
>          pc = 0xc0346514  lr = 0xc0571a74 (kmem_malloc_domainset+0x9c)
>          sp = 0xc0e16c28  fp = 0xc0e16c70
>          r4 = 0x00000006  r5 = 0x000000cc
>          r6 = 0xc0ddc108  r7 = 0xc1e1b000
>          r8 = 0x00000000  r9 = 0x00000000
>         r10 = 0xc0e16c50
> kmem_malloc_domainset() at kmem_malloc_domainset+0x9c
>          pc = 0xc0571a74  lr = 0xc02b3ba0 (malloc_large+0x2c)
>          sp = 0xc0e16c78  fp = 0xc0e16c90
>          r4 = 0x00000002  r5 = 0xffffffff
>          r6 = 0x00000d90  r7 = 0x00000000
>          r8 = 0xc08ac904  r9 = 0xc0766709
>         r10 = 0x80000803
> malloc_large() at malloc_large+0x2c
>          pc = 0xc02b3ba0  lr = 0xc067c37c (ti_sysc_attach+0x19c)
>          sp = 0xc0e16c98  fp = 0xc0e16cd0
>          r4 = 0xd11d3e00  r5 = 0xffffffff
>          r6 = 0x00000d90  r7 = 0xd11d3e28
>          r8 = 0x00000d90 r10 = 0x80000803
> ti_sysc_attach() at ti_sysc_attach+0x19c
>          pc = 0xc067c37c  lr = 0xc0316678 (device_attach+0x50c)
>          sp = 0xc0e16cd8  fp = 0xc0e16d20
>          r4 = 0xc25e4680  r5 = 0xc25e4a80
>          r6 = 0x36a26d7e  r7 = 0x00000000
>          r8 = 0xc0b2e824  r9 = 0x80040001
>         r10 = 0x80000803
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.