[Bug 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028

--- Comment #212 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
For a successful boot, could you report the local equivalent of:

# kgdb # So: the live system (not what I was actually doing)
. . .
(kgdb) disass btext
Dump of assembler code for function btext:
   0xffffffff8038e000 <+0>:     push   $0x2
   0xffffffff8038e002 <+2>:     popf
   0xffffffff8038e003 <+3>:     mov    %rsp,%rbp
   0xffffffff8038e006 <+6>:     mov    0x4(%rbp),%edi
   0xffffffff8038e009 <+9>:     mov    0x8(%rbp),%esi
   0xffffffff8038e00c <+12>:    mov    $0xffffffff81d84580,%rsp
   0xffffffff8038e013 <+19>:    xor    %ebp,%ebp
   0xffffffff8038e015 <+21>:    call   0xffffffff8108dca0 <hammer_time>
   0xffffffff8038e01a <+26>:    mov    %rax,%rsp
   0xffffffff8038e01d <+29>:    call   0xffffffff80b7d260 <mi_startup>
   0xffffffff8038e022 <+34>:    hlt
   0xffffffff8038e023 <+35>:    jmp    0xffffffff8038e022 <btext+34>
   0xffffffff8038e025 <+37>:    cs nopw 0x0(%rax,%rax,1)
   0xffffffff8038e02f <+47>:    nop
End of assembler dump.
(kgdb) info files
Symbols from
"/usr/home/root/artifacts/13.4R/usr/lib/debug/boot/kernel/kernel.debug".
Local exec file:
        `/usr/home/root/artifacts/13.4R/boot/kernel/kernel', file type
elf64-x86-64-freebsd.
        Entry point: 0xffffffff8038e000
        0xffffffff802002a8 - 0xffffffff802002b5 is .interp
        0xffffffff802002b8 - 0xffffffff802310f0 is .hash
        0xffffffff802310f0 - 0xffffffff8025f9c0 is .gnu.hash
        0xffffffff8025f9c0 - 0xffffffff802f2450 is .dynsym
        0xffffffff802f2450 - 0xffffffff8036d0c4 is .dynstr
        0xffffffff8036d0c8 - 0xffffffff8038da68 is .rela.dyn
        0xffffffff8038e000 - 0xffffffff811863f8 is .text
        0xffffffff81186400 - 0xffffffff817f8c20 is .rodata
. . . (past the first .text section anyway) . . .

Note that my output above is for the kernel file instead of
for a live system. For all I know a live system might relocate
sections to distinct address ranges vs. the above. That is
part of what I'm checking for your context.

Also:

(kgdb) disass 0xffffffff80cf0110
. . . (various pages later) . . .
A range of  lines spanning at least from somewhat before
0xffffffff80cf011? to somewhat after it.
. . .

(The above will likely name what function it is displaying
-- the one that spans the address listed.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.