Hello @anthoineb,
Thank you. I have attached the requested evidence as separate text files because the forum does not accept ZIP archives:
two complete GDB/tap-ctl captures taken during the same incident, before reboot;
the corresponding daemon.log excerpt from the hypervisor;
the corresponding SMlog excerpt from the hypervisor;
a README containing the timeline and identifiers;
SHA-256 checksums.
Both host-log excerpts cover 2026-07-25 04:35:00-05:10:00 MSK (UTC+03:00).
The first GDB capture started at 04:45:44, the independent repeat capture
started at 04:48:03, and the forced VM reboot was requested at 04:58:33.
Both captures show the same state:
the tapdisk main thread was in scheduler_wait_for_events();
n_reqs=32 and n_reqs_free=32;
req_prod=req_cons=rsp_prod=rsp_prod_pvt=0;
tap-ctl reported reqs_outstanding=0;
the guest still reported 31 requests in flight and all 32 blkfront tags busy.
The host logs contain no tapdisk error before the reboot. At 04:58:34-04:58:36
they show the expected sring disconnect, tapdisk close/detach and clean shutdown
after the forced reboot request. The new QCOW2 tapdisk was opened at 04:59:57
and its sring connected at 05:00:27.
Please let me know if you need another structure printed from GDB or a wider
host-log interval. Our recovery controller can preserve the same pre-reboot
diagnostic window during the next occurrence.
SHA256SUMS.txt README.txt osott-193-SMlog-20260725-0435-0510.txt osott-193-daemon-20260725-0435-0510.txt 20260725-044732-gdb-172.30.52.193.txt 20260725-044544-gdb-172.30.52.193.txt