Skip to content

The network agent's polling mode: refused by all three, and not about the switch's bus, 2026-10-25

Discovery 25 of the discoveries. The network agent on the coprocessor takes a message called SET_POLLING_MODE (0x44) that nothing sends, and the agent's own reads of the switch's bus spoil os-xgs-npu's there (639) - so the message was taken for a way to change how the agent polls, and perhaps a cure. Read in the vendor's GPL release and asked of all three coprocessors - the second XGS 3300 on SFOS 22's software, the first on SFOS 23's, the XGS 136 on SFOS 21's - with octep.ko 6cde3fde and npuep.ko 590205fb (images/deploy/lab-pollmode-report.sh).

What the name belongs to

The host module's header names the message beside a flag of the same name:

#define NWA_MB_POLLING          BIT(16)
#define NWA_MB_COMPATIBLE(mb_magic) (((mb_magic) & ~NWA_MB_POLLING) == NWA_MB_MAGIC_ACCOUNT())

mb_magic is the last field of the agent's answer to SWITCH_INIT, the version word of the mailbox the host and the agent pass messages through. So the polling the flag and the message speak of is the mailbox's - whether the two sides watch it by polling or are woken by a doorbell - and not the agent's reading of the switch. The host module never sends the message, and the agent's code is not in the release. The agent itself, which runs inside the coprocessor's fast-path program on both families, logs a "SOC Agent polling interval" of its own at start; nothing in it is set from the host.

Asked of the three

SET_POLLING_MODE asked of all three coprocessors, payload 0 and 1, beside a link query: the link query answered with status 0 and twelve bytes on each; SET_POLLING_MODE answered with status 1, an error, and eight bytes, every time, on SFOS 22, 23 and 21

a link query (GET 0x04 0x00) SET_POLLING_MODE, payload 0 payload 1
second XGS 3300, SFOS 22 status 0, 12 bytes status 1, 8 bytes status 1, 8 bytes
first XGS 3300, SFOS 23 status 0, 12 bytes status 1, 8 bytes status 1, 8 bytes
XGS 136, SFOS 21 status 0, 12 bytes status 1, 8 bytes status 1, 8 bytes

Every agent refused it, as it refuses the MDIO and GPIO operations (netagent.md), while the same channel answered a link query beside it. Nothing changed on any board, and the coprocessor's log said nothing of it.

What it means for os-xgs-npu

Nothing to build: the message is not implemented by any of the three agents, and what its name speaks of is the mailbox, not the switch's bus. The reads that spoil stay handled as they are - the switch's counters read twice by mvsw, and a register read three times where a single read decides something (qsched-2026-10-25).

What it does not say

  • Which payload the message would carry where it is implemented: none of these agents is one.
  • Whether the agent's own polling interval can be changed some other way.

Discussion

The discussion of this page is held in the project's GitHub Discussions. Showing it here loads giscus from giscus.app and GitHub, and writing in it needs a GitHub account - what that means.