GDB connection fails with "Remote replied unexpectedly to 'vMustReplyEmpty': timeout"
jhand2 opened this issue · comments
(note actual IP address replaced with X.X.X.X)
insmod succeeds and dmesg log looks good:
[ 1275.281811] kgdboe: loading out-of-tree module taints kernel.
[ 1275.281811] kgdboe: module verification failed: signature and/or required key missing - tainting kernel
[ 1275.298549] netpoll: kgdboe: local IP X.X.X.X
[ 1275.298549] kgdboe: single-core mode enabled. Shutting down all cores except #0. This is slower, but safer.
[ 1275.298549] kgdboe: you can try using multi-core mode by specifying the following argument:
[ 1275.298549] insmod kgdboe.ko force_single_core = 0
[ 1275.339718] KGDB: Registered I/O driver kgdboe
[ 1275.358895] kgdboe: Successfully initialized. Use the following gdb command to attach:
[ 1275.358895] target remote udp:X.X.X.X:31337
But when I run target remote udp:X.X.X.X:31337 it fails with the following:
Remote debugging using udp:X.X.X.X:31337
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
I don't have a great idea of how I can fix this.
GDB version is 8.1
Kernel version is 5.6.0
Note that this is a hyper-v VM and the network driver being used is hv_netvsc. I'm not sure if that is supported.
Sorry, we haven't tested kgdboe with the Hyper-V network driver. Generally, when it comes to network drivers, it's usually a hit or miss. If the driver implements the netpoll interfaces and does not internally take any locks that would interfere with debugging, kgdboe will work with it. If not, it will silently fail since the driver will lock up before gdb can receive any meaningful reply.
If Hyper-V provides an internal debugging interface similar to the VWMare gdb stub, you should be able to debug the network driver in conjunction with kgdboe and see what causes it to get stuck. If there's a specific change that needs to be done to kgdboe in order to accomodate hv_netvsc support, we will be happy to receive a pull request resolving it.