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:
+10
-1
@@ -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:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user