diff --git a/docs/modules/fs/README.md b/docs/modules/fs/README.md index f4503ab..c7bcdba 100644 --- a/docs/modules/fs/README.md +++ b/docs/modules/fs/README.md @@ -26,7 +26,7 @@ Protocol and full verified catalog: [bcm84891l-mdio-commands.md](bcm84891l-mdio- - **PASS cannot prove completion.** The previous command's PASS stays latched while a slow firmware still executes, and until then the DATA registers are firmware scratch — the die temperature turns up in them (0x004E–0x0051 observed as "SNR" and "EEE mode"; the campaign's "anomalous 0x0047" was this same race). - **Handler writes during firmware-busy windows wedge the µC permanently** — DATA/CMD writes landing while firmware does post-AN provisioning or training work (a window stretching ~10 s past relink) killed the SMI service four times; reads alone never once. Unmitigated — exposure accepted until the shared-mailbox contention is properly resolved. - **Bridge reads carry no fetch identity** — a fetch that outruns the delay leaves the previous transaction's data at 0xAD with no error. A killed host can also leave the pipeline latched a response behind *persistently* (PHY ID served a stuck stale value across processes until driver re-init); every appliance boot clears it by loading the driver, so only bench runs reusing a loaded driver see it, and the identity check at startup dies loudly on it. -- **Stale reads poisoned the corrected-error channel** — caught with per-register instrumentation: 3.33 reads served 1.147's resident 0x0011 (decoding as exactly 17 errored blocks — the recurring "+17"), SNR DATA values (+21/22), and 1.147 reads served 3.33's 0x8000 (count 16, charged twice by the rollover delta) and the die temperature. Every corrected burst observed to date decodes as a neighbor register; none is proven cable stress, and the noise-correlation was the µC being busy (stale window), not physics. The corrected channel is untrustworthy until the stale-read problem is solved; the internal temp client is a prime suspect for the periodic busy windows. +- **Stale reads poisoned the corrected-error channel** — caught with per-register instrumentation: 3.33 reads served 1.147's resident 0x0011 (decoding as exactly 17 errored blocks — the recurring "+17"), SNR DATA values (+21/22), and 1.147 reads served 3.33's 0x8000 (count 16, charged twice by the rollover delta) and the die temperature. Every corrected burst observed to date decodes as a neighbor register; none is proven cable stress, and the noise-correlation was the µC being busy (stale window), not physics. The corrected channel is untrustworthy until the stale-read problem is solved; the internal temp client is a prime suspect for the periodic busy windows and is not silenceable (firmware-reliability notes). - Poll STATUS ~100 ms; frozen up to 2 s during 10GBASE-T training — only run after link-up. ## Proven diagnostics @@ -55,7 +55,7 @@ Protocol and full verified catalog: [bcm84891l-mdio-commands.md](bcm84891l-mdio- ## Firmware-reliability notes -**The firmware is its own mailbox client — the handler is a shared, unarbitrated resource.** Watched read-only on an idle module: CMD sits at 0x0031 (`CMD_GET_CURRENT_TEMP`, bit 15 consumed) and DATA1 tracks the live die temperature (0x4F–0x52 ≈ 79–82 °C under load), refreshed every ~3.5 s — the firmware issues its own temperature command through the same CMD/STATUS/DATA registers the host uses, with no arbitration. Every mystery this explains: temperature appearing in DATA1 (it is that command's output — the campaign's "anomalous 0x0047" included), PASS satisfying a host poll when it belongs to the internal command, and the µC wedges (two writers colliding on CMD/DATA, likeliest when internal management activity spikes after AN events). The host side keeps exactly one conversation open at a time (one per-module lock around every whole operation, `phy.go`) and confines writes to quiet windows; **contention with the internal client is otherwise unresolved** — a host GET can still be preempted (~10% per command at the temp cadence) and its results replaced. Any GET whose answer lives in DATA1 is unusable; corroborate through IEEE registers or the wire. The hard rule that stands: write every DATA register explicitly before any SET — the handler executes stale DATA. +**The firmware is its own mailbox client — the handler is a shared, unarbitrated resource.** Watched read-only on an idle module: CMD sits at 0x0031 (`CMD_GET_CURRENT_TEMP`, bit 15 consumed) and DATA1 tracks the live die temperature (0x4F–0x52 ≈ 79–82 °C under load), refreshed every ~3.5 s — the firmware issues its own temperature command through the same CMD/STATUS/DATA registers the host uses, with no arbitration. Every mystery this explains: temperature appearing in DATA1 (it is that command's output — the campaign's "anomalous 0x0047" included), PASS satisfying a host poll when it belongs to the internal command, and the µC wedges (two writers colliding on CMD/DATA, likeliest when internal management activity spikes after AN events). The host side keeps exactly one conversation open at a time (one per-module lock around every whole operation, `phy.go`) and confines writes to quiet windows; **contention with the internal client is otherwise unresolved** — a host GET can still be preempted (~10% per command at the temp cadence) and its results replaced. Any GET whose answer lives in DATA1 is unusable; corroborate through IEEE registers or the wire. The hard rule that stands: write every DATA register explicitly before any SET — the handler executes stale DATA. **The internal poll is not silenceable through the handler**: disabling the temperature warning (SET 0x8032 `(0x007D, 5, 0, 0, 0)` and 0x8034 `(0xFFD8, 5, 0, 0, 0)` — DATA3 = 0 = warning off — both PASS) leaves CMD resident at 0x0031 with DATA1 tracking the die within seconds of the host going quiet; the ~3.5 s poll is independent of the warning machinery. GET 0x8033/0x8035 read DATA1–3 = 0 before and after those SETs (DATA4/5 leftover scratch) — DATA1-answer readbacks, unusable as verification either way. ## ECD — recovered from the OpenBCM SDK, proven on hardware diff --git a/docs/modules/fs/bcm84891l-mdio-commands.md b/docs/modules/fs/bcm84891l-mdio-commands.md index f2788aa..9763f97 100644 --- a/docs/modules/fs/bcm84891l-mdio-commands.md +++ b/docs/modules/fs/bcm84891l-mdio-commands.md @@ -474,6 +474,13 @@ temperature-like values can leak into other commands' DATA1. temperature limit margin in °C (positive number). DATA3: Enable upper temperature warning — 0 = Disable, 1 = Enable. +**Field note (hardware-verified):** disabling the warning — SET 0x8032 `(0x007D, 5, 0, 0, 0)` +and SET 0x8034 `(0xFFD8, 5, 0, 0, 0)`, DATA3 = 0, all five params explicit, both PASS — does +not stop the firmware's own ~3.5 s internal CMD_GET_CURRENT_TEMP poll (README +firmware-reliability notes); the warning machinery and the internal temperature poll are +independent. GET 0x8033/0x8035 return DATA1–3 = 0 regardless of prior SET values, with +DATA4/5 reading leftover scratch — DATA1-answer readbacks that cannot verify anything. + ### §1.25.1.30 GET_WAP_MODE_FRAME_TYPE (0x8023) - **Description:** — diff --git a/docs/open-questions.md b/docs/open-questions.md index 4e0dbf7..25c0779 100644 --- a/docs/open-questions.md +++ b/docs/open-questions.md @@ -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: