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

BCM path proven on X520: fix multi-byte i2c read (SDA release), GET_SNR is 0x8030 invoked bare, IEEE SNR regs dead on BCM, module pause forced off

Browse Source
This commit is contained in:
flamingcow
2026-08-12 17:50:14 -07:00
parent 6f787c0873
commit 01e00dfffe
3 changed files with 16 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/state.md
+8 -7
View File
@@ -15,17 +15,18 @@ AF_PACKET raw sockets everywhere (`sock.go`), flow-director steering, per-packet
- 1× Fibergaga SFP-10G-T-30M (Aquantia, RollBall, the proven oracle module).
- 1× 10Gtek, EEPROM claims SFP-10G-SR — still a copper RJ45 module; filler, not part of the test set.
## X520 prep — built ahead of the card, untested (no hardware yet)
In `~/work/` alongside the ice-sff/phydiag-work artifacts, ready to fold into the repo's `kernel/` once validated on real hardware:
- **Patched ixgbe** (`~/work/ixgbe-sff/`, built against the running kernel, vermagic matches): adds `ixgbe_i2c_raw_write`/`ixgbe_i2c_raw_read` in `ixgbe_phy.c` (arbitrary START…STOP transactions built from the existing bit-bang primitives, swfw-semaphore bracketed) and an `sff_i2c` debugfs file with `w <addr8> <bytes…>` / `r <addr8> <n>` commands, result read back from the fd. Modeled on the proven ice `sff_i2c`; ixgbe has no firmware to refuse, so arbitrary framing works. `load-ixgbe` rebuilds + swaps the module.
- **BCM client** (`~/work/phydiag-work/bcm_ixgbe.py`): BCM SMI framing on those two ops (read = write `[001+devad,RegH,RegL]`, >1 ms delay, read 2 B; write = 5-byte frame) plus the full command handler (`_wait_idle` → DATA → CMD|bit15 → poll PASS/ERROR → read DATA), `CMD_GET_SNR` decoded to per-pair dB, and EEPROM/PHY-ID/STATUS sanity reads.
- **RollBall client for the Wiiteks** (`~/work/phydiag-work/rollball_ixgbe.py`): the same `sff_i2c` transport, RollBall unlock/page/mailbox, per-pair IEEE SNR (PMA 1.133–1.136). The `*.0x??64` (high-byte ≥ 0x80) brick blacklist is a hard guard that raises *before* touching hardware — the client structurally cannot repeat the kill.
## X520 diagnostics path — validated on hardware
In `~/work/` alongside the ice-sff/phydiag-work artifacts, ready to fold into the repo's `kernel/`:
- **Patched ixgbe** (`~/work/ixgbe-sff/`): adds `ixgbe_i2c_raw_write`/`ixgbe_i2c_raw_read` in `ixgbe_phy.c` (arbitrary START…STOP transactions built from the existing bit-bang primitives, swfw-semaphore bracketed) and an `sff_i2c` debugfs file with `w <addr8> <bytes…>` / `r <addr8> <n>` commands, result read back from the fd. **Proven on the card after one real bug**: multi-byte reads returned only byte 0 — the master's ACK left SDA driven low and nothing released it (stock 82599 paths never clock in more than one byte, so the missing release was invisible until now); `raw_read` now releases SDA after each ACK, mirroring the release block stock uses after clocking out a byte. `load-ixgbe` rebuilds + swaps the module and passes `allow_unsupported_sfp=1` (mandatory for the FS).
- **BCM client** (`~/work/phydiag-work/bcm_ixgbe.py`): BCM SMI framing proven end-to-end on the FS — EEPROM, PHY ID 0x3590:5081, handler STATUS, and per-pair SNR ≈ [32, 27.5, 30, 27.6] dB on the bench cable via `CMD_GET_SNR = 0x8030` invoked with no DATA1 write (see transports.md for the code-table trap and the pause-mode side quest).
- **RollBall client for the Wiiteks** (`~/work/phydiag-work/rollball_ixgbe.py`): the same `sff_i2c` transport, RollBall unlock/page/mailbox, per-pair IEEE SNR (PMA 1.133–1.136), untested on this card. The `*.0x??64` (high-byte ≥ 0x80) brick blacklist is a hard guard that raises *before* touching hardware — the client structurally cannot repeat the kill.
## Bringup plan when the X520 arrives
1. Card installed and modules seated (done). Next: `./load-ixgbe` with `allow_unsupported_sfp=1` (mandatory — the FS's honest 10GBASE-T EEPROM fails Intel qualification and kills the port probe; `ixgbe_main.c:165`), confirm `sff_i2c` appears.
2. FS/BCM modules first: `bcm_ixgbe.py` sanity reads (EEPROM, PHY ID, STATUS) to prove the SMI transport, then the command handler (CMD_GET_SNR vs the IEEE registers) on the test cable set.
1. Card installed, modules seated, `./load-ixgbe` with `allow_unsupported_sfp=1` (mandatory — the FS's honest 10GBASE-T EEPROM fails Intel qualification and kills the port probe; `ixgbe_main.c:165`), `sff_i2c` present. Done.
2. FS/BCM proven: SMI transport, EEPROM/PHY-ID/STATUS sanity, command handler (temp, voltage, per-pair SNR). The IEEE-register SNR path is dead on the BCM — the command handler is the source. Done.
3. Replacement Wiiteks: IEEE-standard registers only (SNR, latches) unless/until a documented recipe exists for more; the VCT templates in modules.md are candidates for single-shot targeted probes on a sacrificial unit only.
4. Re-derive host tuning on ixgbe (coalescing/ring syntax differs).
5. RX steering: program/verify the ETQF path (open-questions.md §1) before cabletest traffic runs.
## Open: RX flow-steering on ixgbe needs serious investigation before the X520 carries test traffic
cabletest fans RX across queues by steering **raw ethertype** (0x88b5 base) to distinct queues with Flow Director rules (`system.go`, ETHTOOL_SRXCLSRLINS, ETHER_FLOW). The obvious path fails: ixgbe/82599's `ixgbe_flowspec_to_flow_type` accepts only TCP/UDP/SCTP-v4 and IPv4 — **no ETHER_FLOW** — so an ETHER_FLOW rule insert is rejected (EINVAL) and the tool fails at startup (no fallback, by design). This is a datapath issue affecting *both* module types, independent of diagnostics.