evan
9b8c6ba925
E15/E16: runtime store-gating bisection plus repeated-run testing show the 0x4201e210 reader-open corruption is a race (identity-independent, config alternates crash/pass), not a miscompiled TB. Blanket store-TCI suppresses it in practice. Wire ?sthash and ?stcw/stcmask/stcval opt-in debug controls.
4.2 KiB
Known Issues
Resolved: directory-backed SD reads corrupted WASM state
Opening /Test/example.txt through QEMU vvfat could corrupt coroutine/guest state. The browser now builds a standards-compliant 64 MiB FAT32 image from OPFS and mounts it as a raw block device, bypassing the failing host-file mapping path. The official CrossPoint 1.4.1 firmware can traverse Test/example.txt without a WASM trap or guest panic.
Resolved: SD card remained in receivingdata
ssi-sd consumed a write-data token while leaving response mode, then parsed payload bytes as commands. The adapter now enters token mode immediately after the final R1 byte. SPI CMD13 also uses the upstream-correct sd_r1 internal response so status polling no longer loops on Unexpected response to cmd 13.
Upstream limitation: compiled wasm32 store path (perf ceiling)
Opening a book panics only in WASM (Invalid read ... reason: rejected → Load access fault) inside uzlib_uncompress during the reader's font prewarmCache if compiled guest stores are enabled. Native QEMU from the same submodule renders fine.
Root cause (updated, E15/E16): the corruption is a nondeterministic race, not a deterministic miscompilation. Per-TB compiled store codegen is bit-identical to TCI (E10/E11, 300k+ comparisons). Runtime store-gating bisection showed the crash does not depend on any specific store TB's identity — only on enough compiled stores of both widths running — and the same fixed config alternates CRASH/PASS across runs. Prime suspect is shared-memory ordering / concurrency between the compiled store path and another agent touching guest RAM (IO-thread device models, dirty/notdirty handling, or the Asyncify store slow-path DONE_FLAG/UNWINDING re-entrancy). wasm_tci_only_tb = true in tcg_out_qemu_st (upstream qemu-wasm's blanket store-TCI) suppresses the race in practice: 0 corruption crashes over 4 clean runs (a 5th failure was an unrelated cold-boot watchdog flake).
Remaining fix is to eliminate the race so compiled stores are safe and the blanket TCI can be dropped — a TCG-backend/threading task, ~15 min per browser iteration, no native repro. Opt-in debug tools: ?nostoretci (all stores compiled, reproduces the race), ?sthash, ?stcw/stcmask/stcval. Full analysis: docs/wasm-inflate-panic.md.
Resolved: -icount throttled book open ~4.7x
The browser ran with -icount shift=auto,align=off,sleep=off, which serialized TCG and starved the guest watchdog (the earlier wdt timeout panics). Measured book open: 146s with icount, 31s without. icount is now off by default in web/app.js; ?icount restores it. Guest timekeeping tracks host wall-clock, which is fine here because running flat-out feeds the watchdog faster, not slower.
Resolved: reader grayscale rendered inverted and muddled
The reader drew a crisp BW page, then a 4-level grayscale antialiasing pass (inverted plane polarity, near-empty planes) that the old model rendered as a full frame, wiping the page to an inverted muddle. The xteink_x3_eink model now keeps a persistent surface, identifies known BW and grayscale modes by exact comparison of the complete loaded LUT bank, and treats grayscale level 0 as no-drive (keep pixel) so only antialiased edges repaint over the retained BW page. Unknown LUTs are logged and skipped instead of guessed from pixel content. Reader text renders sharp on native and wasm.
Resolved: cold boot required a manual power-button hold
The browser now presses power after the panel's initial frame, releases it on the next frame (the Booting screen), and only then enables controls. This mirrors the previously reliable browser-test sequence without relying on a wall-clock delay. The browser test no longer presses power itself, proving cold boot is automatic. The preceding NVS NOT_FOUND messages remain expected first-boot initialization noise.
WASM heap balloons after watchdog reboot
The committed WASM heap starts near 176.3 MiB but can grow to approximately 631.8 MiB after the watchdog reboot described above.
This indicates translated-block or dynamic WebAssembly module state is retained across guest reboot. TB cleanup must release old dynamic instances during reset; reboot-time growth should remain bounded.