Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: <pcib1 memory window> request" leads to panic

On Feb 12, 2024, at 10:02, John Kennedy <[email protected]> wrote:

> On Mon, Feb 12, 2024 at 09:36:46AM -0800, John Baldwin wrote:
>> Without a stack trace it is pretty much impossible to debug a panic like this.
>> Do you have KDB_TRACE enabled in your kernel config?  I'm also not sure how the
>> PCI changes can result in a panic post-boot.  If you were going to have problems
>> they would be during device attach, not after you are booted and running X.
>> 
>> Short of a stack trace, you can at least use lldb or gdb to lookup the source
>> line associated with the faulting instruction pointer (as long as it isn't in
>> a kernel module), e.g. for gdb you would use 'gdb /boot/kernel/kernel' and then
>> 'l *<instruction pointer address>', e.g. from above: 'l *0xffffffff80acb962'
> 
>  I know on my RPI4 where I saw that, my USB keyboard was dead at that point
> and I couldn't get a trace or continue along to get the crashdump.

My serial console context still works at the panic.
But:

 . .
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x4c: str     xzr, [x19, #1280]
db> dump
Cannot dump: no dump device specified.
db> 

This is despite:

# grep dumpdev /boot/loader.conf
dumpdev="/dev/da0p3"

and:

# gpart show -p
=>       40  468862048    da0  GPT  (224G)
         40      32728         - free -  (16M)
      32768     102400  da0p1  efi  (50M)
     135168  451809280  da0p2  freebsd-ufs  (215G)
  451944448   16916480  da0p3  freebsd-swap  (8.1G)
  468860928       1160         - free -  (580K)

So, the panic may be before dumping is set up, at
least for USB3 media.

===
Mark Millard
marklmi at yahoo.com