theater/cabletest
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Windowed module protocol: every op admitted inside a 3.4s window after the firmware's observed temp poll (cadence 3.5-4.2s measured, stuck-at-last-fetch stale mechanism proven and avoided), acquire/window with panic on dead heartbeat; noise column shows green on/off cycle phase, cable-missing state unchanged

Browse Source
This commit is contained in:
flamingcow
2026-08-13 14:04:16 -07:00
parent d81594ffbf
commit a9f10d3055
8 changed files with 104 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/open-questions.md
+1 -10
View File
@@ -22,16 +22,7 @@ The register question is answered (post-FEC vs corrected-by-iteration histogram
No confirmed-safe path exists (every candidate lands in the µC danger window). The open decision is whether the capability is worth the NDA route or a sacrificial unit — the product doesn't need it for length ([modules/wiitek/](modules/wiitek/README.md), [modules/README.md](modules/README.md)).
## 5. Corrected-error channel under the internal temp client
Every corrected-error burst observed decodes as a stale neighbor register served under a busy
µC, and the firmware's internal ~3.5 s GET_CURRENT_TEMP poll — the prime suspect for the busy
windows — is not silenceable through the handler (temp-warning disable leaves it running,
proven on hardware — [modules/fs/](modules/fs/README.md)). The corrected channel stays
untrustworthy; the remaining path is the register-docs ask (Wiitek request sent; the FS
missing-chapter asks pending).
## 6. X520 bench divergences — features to restore on the product NIC
## 5. X520 bench divergences — features to restore on the product NIC
Running on the X520 (BCM development) required parking product-NIC capabilities the 82599 lacks. Each stays parked only until the ConnectX-5 is in; none is a settled design change: