[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 #214 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
Interesting. Your context:

Local exec file:
        `/boot/kernel/kernel', file type elf64-x86-64-freebsd.
        Entry point: 0xffffffff8038e000
        0xffffffff802002a8 - 0xffffffff802002b5 is .interp
        0xffffffff802002b8 - 0xffffffff80231108 is .hash
        0xffffffff80231108 - 0xffffffff8025f9e4 is .gnu.hash
        0xffffffff8025f9e8 - 0xffffffff802f24c0 is .dynsym
        0xffffffff802f24c0 - 0xffffffff8036d162 is .dynstr
        0xffffffff8036d168 - 0xffffffff8038db08 is .rela.dyn
        0xffffffff8038e000 - 0xffffffff811843f8 is .text
        0xffffffff81184400 - 0xffffffff817f68d0 is .rodata
. . .

The downloaded kernel.txz expanded:

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
. . .

And, your context:

(kgdb) disass 0xffffffff80cf0110
Dump of assembler code for function strcmp:
   0xffffffff80cf0100 <+0>:     push   %rbp
   0xffffffff80cf0101 <+1>:     mov    %rsp,%rbp
   0xffffffff80cf0104 <+4>:     xor    %ecx,%ecx
   0xffffffff80cf0106 <+6>:     cs nopw 0x0(%rax,%rax,1)
   0xffffffff80cf0110 <+16>:    movzbl (%rdi,%rcx,1),%eax
   0xffffffff80cf0114 <+20>:    movzbl (%rsi,%rcx,1),%edx
   0xffffffff80cf0118 <+24>:    cmp    %dl,%al
   0xffffffff80cf011a <+26>:    jne    0xffffffff80cf0127 <strcmp+39>
   0xffffffff80cf011c <+28>:    inc    %rcx
   0xffffffff80cf011f <+31>:    test   %eax,%eax
   0xffffffff80cf0121 <+33>:    jne    0xffffffff80cf0110 <strcmp+16>
   0xffffffff80cf0123 <+35>:    xor    %eax,%eax
   0xffffffff80cf0125 <+37>:    pop    %rbp
   0xffffffff80cf0126 <+38>:    ret
   0xffffffff80cf0127 <+39>:    sub    %edx,%eax
   0xffffffff80cf0129 <+41>:    pop    %rbp
   0xffffffff80cf012a <+42>:    ret
End of assembler dump.

My 13.4-RELEASE kernel.txz expansion:

(kgdb) disass strcmp
Dump of assembler code for function strcmp:
   0xffffffff80cf2290 <+0>:     push   %rbp
   0xffffffff80cf2291 <+1>:     mov    %rsp,%rbp
   0xffffffff80cf2294 <+4>:     xor    %ecx,%ecx
   0xffffffff80cf2296 <+6>:     cs nopw 0x0(%rax,%rax,1)
   0xffffffff80cf22a0 <+16>:    movzbl (%rdi,%rcx,1),%eax
   0xffffffff80cf22a4 <+20>:    movzbl (%rsi,%rcx,1),%edx
   0xffffffff80cf22a8 <+24>:    cmp    %dl,%al
   0xffffffff80cf22aa <+26>:    jne    0xffffffff80cf22b7 <strcmp+39>
   0xffffffff80cf22ac <+28>:    inc    %rcx
   0xffffffff80cf22af <+31>:    test   %eax,%eax
   0xffffffff80cf22b1 <+33>:    jne    0xffffffff80cf22a0 <strcmp+16>
   0xffffffff80cf22b3 <+35>:    xor    %eax,%eax
   0xffffffff80cf22b5 <+37>:    pop    %rbp
   0xffffffff80cf22b6 <+38>:    ret
   0xffffffff80cf22b7 <+39>:    sub    %edx,%eax
   0xffffffff80cf22b9 <+41>:    pop    %rbp
   0xffffffff80cf22ba <+42>:    ret
End of assembler dump.

Same code, different address range.

It does not look like I can investigate backtraces
via just the kernel*.txz contents. That invalidates
a lot of my older notes that involve such.

strcmp is in your context is at least believable,
presuming the address interpretation of the blur
is accurate: the nice start of an instruction
could well produce the general protection fault:

   0xffffffff80cf0110 <+16>:    movzbl (%rdi,%rcx,1),%eax

Most bad values would not point to an intended
instruction start of an instruction that could
generate the initially reported failure.

For reference, for the kernel.txz expansion:

# strings boot/kernel/kernel | grep "\-RELEASE "
@(#)FreeBSD 13.4-RELEASE releng/13.4-n258257-58066db597be GENERIC
FreeBSD 13.4-RELEASE releng/13.4-n258257-58066db597be GENERIC

-- 
You are receiving this mail because:
You are the assignee for the bug.