[Bug 294120] virtio_blk: cannot dump core after c8c37141a661cc9a6a51e43599d1afc8a3f0ef46

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

            Bug ID: 294120
           Summary: virtio_blk: cannot dump core after
                    c8c37141a661cc9a6a51e43599d1afc8a3f0ef46
           Product: Base System
           Version: 16.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: asomers@FreeBSD.org

It is no longer possible for me to write a core dump in my VM using a
virtio-blk disk.  When I try, I get an error like the below.  I've narrowed the
breakage down to one commit
https://github.com/freebsd/freebsd-src/commit/c8c37141a661cc9a6a51e43599d1afc8a3f0ef46
.

Steps to Reproduce
==================

1) Create a FreeBSD 16.0-CURRENT x86_64 BHyve VM with a virtio-blk disk and
configure it as a dump device.
2) trigger a panic, with sudo sysctl debug.kdb.panic=1
3) On the serial console, type "dump"

Console Output
==============

login: panic: kdb_sysctl_panic
cpuid = 5
time = 1774797651
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00d92eba20
vpanic() at vpanic+0x136/frame 0xfffffe00d92ebb50
panic() at panic+0x43/frame 0xfffffe00d92ebbb0
kdb_sysctl_panic() at kdb_sysctl_panic+0x63/frame 0xfffffe00d92ebbe0
sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame
0xfffffe00d92ebc30
sysctl_root() at sysctl_root+0x22f/frame 0xfffffe00d92ebcb0
userland_sysctl() at userland_sysctl+0x1b6/frame 0xfffffe00d92ebd50
sys___sysctl() at sys___sysctl+0x65/frame 0xfffffe00d92ebe00
amd64_syscall() at amd64_syscall+0x1c4/frame 0xfffffe00d92ebf30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00d92ebf30
--- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x3c4f12192b8a, rsp =
0x3c4f1115f7c8, rbp = 0x3c4f1115f810 ---
KDB: enter: panic
[ thread pid 4883 tid 100251 ]
Stopped at      kdb_enter+0x33: movq    $0,0x15f6322(%rip)
db> dump
Dumping 675 out of 16343 MB:KDB: reentering
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00d92eb020
kdb_reenter() at kdb_reenter+0x2b/frame 0xfffffe00d92eb030
calltrap() at calltrap+0x8/frame 0xfffffe00d92eb030
--- trap 0xc, rip = 0xffffffff809ee1f6, rsp = 0xfffffe00d92eb100, rbp =
0xfffffe00d92eb2e0 ---
vtblk_dump() at vtblk_dump+0xa6/frame 0xfffffe00d92eb2e0
_dump_append() at _dump_append+0x154/frame 0xfffffe00d92eb350
blk_write() at blk_write+0x156/frame 0xfffffe00d92eb3a0
cpu_minidumpsys() at cpu_minidumpsys+0x92b/frame 0xfffffe00d92eb450
dumpsys_generic() at dumpsys_generic+0x5a/frame 0xfffffe00d92eb530
doadump() at doadump+0x88/frame 0xfffffe00d92eb550
db_dump() at db_dump+0x2a/frame 0xfffffe00d92eb570
db_command() at db_command+0x30d/frame 0xfffffe00d92eb630
db_command_loop() at db_command_loop+0x4d/frame 0xfffffe00d92eb640
db_trap() at db_trap+0xe6/frame 0xfffffe00d92eb6d0
kdb_trap() at kdb_trap+0x24f/frame 0xfffffe00d92eb820
trap() at trap+0x79d/frame 0xfffffe00d92eb950
calltrap() at calltrap+0x8/frame 0xfffffe00d92eb950
--- trap 0x3, rip = 0xffffffff80c29d63, rsp = 0xfffffe00d92eba28, rbp =
0xfffffe00d92ebb50 ---
kdb_enter() at kdb_enter+0x33/frame 0xfffffe00d92ebb50
panic() at panic+0x43/frame 0xfffffe00d92ebbb0

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