Re: kgdb with bhyve -G : cannot set debug.kdb.current=gdb

> > >
> > > > [...]
> > > >
> > > > i am unable to solve the following problem:
> > > >
> > > > using kgdb requires the following:
> > > >
> > > > # sysctl debug.kdb.current=gdb
> > >
> > > This is not required when connecting to the gdb stub in bhyve(8)
> > > (enabled with the -G flag). In that case, the gdb stub lives in the
> > > hypervisor, not in the kernel.
> > >
> > > debug.kdb.current is for when you're connecting directly to the
> > > in-kernel gdb stub over the serial console or post-panic network stack
> > > (see netgdb(4)).
> > >
> > > > [...]
> > >
> > > This sounds like a bug in the bhyve gdb stub. Can you share a recipe
> > > for how you're triggering the panic?
> >
> > Hello Mark,
> > Thank you for your message.
> > so, I understand better now how this works, that GDB is inside bhyve in this case.
> > because of this I think the problem is that the host that I'm running bhyve from is running 12.4. on this isolated physical machine my upgrade process has been delayed/blocked and also I'm being extremely cautious on some things.
> > so I will try moving this over to machine with a supported release, and reply again with the results.
> >
> > however, for reference, here is what I do to trigger this panic.
>
>
> Does the machine have an AMD CPU? If so, I think what you're seeing
> might be expected to some extent. Upgrading to 13.5 or a newer 14.x
> release ought to fix it, but I'm not certain--please let us know if not.

yeah it's an AMD CPU;
I tried this on another system (also AMD), running 13.5 this time,
and it also panic'ed, but in this case it was a slightly different
backtrace.

for the g_access breakpoint. it also happens for other breakpoints

root@:~ # less -f /dev/vtbd0


Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer     = 0x20:0xffffffff808ce99d
stack pointer           = 0x28:0xfffffe004a764960
frame pointer           = 0x28:0xfffffe004a7649b0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, IOPL = 0
current process         = 836 (less)
trap number             = 3
panic: breakpoint instruction fault
cpuid = 0
time = 1749497167
KDB: stack backtrace:
#0 0xffffffff809d7915 at kdb_backtrace+0x65
#1 0xffffffff8098af42 at vpanic+0x182
#2 0xffffffff8098adb3 at panic+0x43
#3 0xffffffff80dfc169 at trap_fatal+0x389
#4 0xffffffff80dd2c48 at calltrap+0x8
#5 0xffffffff808c6ae0 at g_dev_open+0xa0
#6 0xffffffff8081c9b0 at devfs_open+0x140
#7 0xffffffff80e7d5bd at VOP_OPEN_APV+0x1d
#8 0xffffffff80a7ff4f at vn_open_vnode+0x1df
#9 0xffffffff80a7fae4 at vn_open_cred+0x5f4
#10 0xffffffff80a75abc at openatfp+0x26c
#11 0xffffffff80a7582d at sys_openat+0x3d
#12 0xffffffff80dfca45 at amd64_syscall+0x105
#13 0xffffffff80dd355b at fast_syscall_common+0xf8


i think the difference between the two backtraces is that this
one does not contain the g_access frame (or wherever i set the
breakpoint)


in this case the host is 13.5-RELEASE n259162-882b9f3f2218
unfortunately I don't have any physical machines running 14.x
(except for a Raspberry Pi 4B), but just give me the word and 
I'll try anything that might help.