| fix(debug): keep SIMD VF debug transfer alive on 3510 The scalar-side consumer could hang the kernel or silently drop records. asc_vf_debug_publish retried forever when a UB batch was larger than the GM ring buffer. That failure is permanent once simd_printf_fifo_size_per_core leaves ringBufLen below the 2024-byte payload, so asc_vf_debug_ub2gm spun without ever reaching its finish/assert exits. Drop the batch instead: advance readLen to release the producer and raise flag to stop the loop, matching what the aicore path already does. Failures from check_ringbuf_space stay retryable since those are only RTS lagging behind. asc_vf_debug_ub2gm polled the UB header through non-volatile loads, so the compiler hoisted them out of the loop and the consumer worked off a stale snapshot, observing finish == 1 while writeLen still read 0 and exiting without transferring anything. finish is set on the scalar unit while the records are written by the VF unit, so observing it does not imply the VF writes are visible yet. Sync the pipes and re-check before concluding the buffer is empty. The producer spin loops now also bail out on flag so they cannot wait on a consumer that has already left; assert then traps without its message instead of hanging. Also name both drop causes in the overflow warning, and document the recommended simd_printf_fifo_size_per_core for SIMD VF. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 23 天前 |
