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

| 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.
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.