On Feb 12, 2024, at 10:02, John Kennedy <warl...@phouka.net> 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
