dangernoodle-io / breadboard / 26238406363

100%

push

github

fix(bb_diag): drop per-write CRC in panic-capture tap (B1-227) (#300)

bb_diag_panic_capture_write was recomputing a CRC32 over the *entire*
accumulated buffer on every log line. The tap runs in the producer's
task context (mining_hw, httpd worker, stratum, …), so the CPU cost
compounds inside whichever task is generating the log line.

On classic ESP32 (no -S3 acceleration) under SSE log-stream load the
cost stalls mining_hw past its 60 s task watchdog. Bench reproduces a
task_wdt panic every ~50 min on TaipanMiner esp32-wroom32 (.81),
backtrace pinning bb_diag_panic_capture_write → bb_crc32 in mining_hw
on CPU 1. Same hook running with extra stack frames also pushes
tight-stack tasks (httpd worker, 6 KB) into overflow on ESP32-S3
(bitaxe-650, tdongle-s3), corrupting adjacent heap and surfacing as
lwip-internal asserts that look unrelated until you trace far enough.

Drop the per-write CRC. The validity check at init now relies on the
magic value plus a length-bound check — a panic that interrupts a
write leaves at worst a few bytes of garbage at the buffer tail, which
is acceptable for a best-effort post-mortem log. The bb_crc32 helper
is removed; the .crc struct field is kept (renamed crc_unused) so the
RTC layout doesn't shift for projects that mix-and-match BB versions
across reboots.

Resolves B1-227. Also addresses B1-226 (empty-panic-dump symptom) and
the cross-board lwip-assert class on bitaxe-650 / tdongle-s3 which
both root at this same hook.

1206 of 1206 branches covered (100.0%)

Branch coverage included in aggregate %.

2088 of 2088 relevant lines covered (100.0%)

921.2 hits per line