panic: Too many early devmap mappings

[bob prohaska]

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]"

[freebsd-arm mailing list]

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]"

[bob prohaska]

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]"

[freebsd-arm mailing list]

[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]"

[freebsd-arm mailing list]

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]"

[bob prohaska]

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]"

[tech-lists]

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.

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.

[Mitchell Horne]

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]"

[freebsd-arm mailing list]

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]"

[bob prohaska]

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]"

[tech-lists]

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.

[Mitchell Horne]

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]"

[freebsd-arm mailing list]

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]"

[tech-lists]

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.

[tech-lists]

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.

I know. I thought my issue and this issue might be linked given that
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.