On Wed, May 20, 2026 at 4:47 AM Zane Leung <[email protected]> wrote:
>
> Hi,
>
> When creating a large number of cores (80+) and connecting them via SMP, GDB
> connection fails with the following errors:
>
> ```
> (gdb) target remote 10.0.90.107:1024
> Remote debugging using 10.0.90.107:1024
> Remote replied unexpectedly to 'vMustReplyEmpty':
> PacketSize=4000;qXfer:memory-map:read-;qXfer:features:read+;qXfer:threads:read+;QStartNoAckMode+;vContSupported+
> (gdb)
> ```
>
> ```
> x100.cpu.78 halted due to undefined.
> x100.cpu.79 halted due to undefined.
> Info : New GDB Connection: 1, Target x100.cpu.0, state: halted
> Error: GDB missing ack(2) - assumed good
> Error: GDB missing ack(2) - assumed good
> Info : dropped 'gdb' connection
> ```
>
> Best regards,
>
> Zane
Hi Zane,
I don't have a target with so many cores in SMP, but I can easily
replicate the error messages with a single core target by adding a
delay in the event gdb-attach :
openocd -f board/stm32mp13x_dk.cfg -c 'stm32mp13x.cpu configure -event
gdb-attach { sleep 5000; halt }'
The issue is caused by GDB that has a 2 seconds timeout to complete
the connection with the remote GDB server (OpenOCD for us).
With the delay in the event or with the latency to halt 80 cores, the
timeout expires.
I can workaround it by adding the GDB command
set remotetimeout 10
before the connection command
target extended-remote :3333
Please check and let us know if such a workaround works for you too.
Few years ago I made a patch to send keep-alive to GDB during the
attach phase, explicitly for this situation, but I cannot find it
anymore in gerrit.
My use case was a target that can only be halted in non-secure, so
OpenOCD has to wait for the firmware to jump from secure to non-secure
execution before halting it and alerting GDB.
I will continue looking for it and eventually rebasing it on current code.
I expect it would fix your issue too, and I would be glad to get you
confirmation.
Regards
Antonio
