Temp-warning disable proven not to silence the firmware's internal temp poll; corrected-error channel stays untrustworthy, register-docs ask is the remaining path (open-questions §5)

This commit is contained in:
flamingcow
2026-08-13 11:03:47 -07:00
parent a3de66f746
commit d81594ffbf
3 changed files with 19 additions and 3 deletions
+10 -1
View File
@@ -22,7 +22,16 @@ 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. X520 bench divergences — features to restore on the product NIC
## 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
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: