On Fri, Jan 10, 2020 at 04:53:06PM +0000, ѽ҉ᶬḳ℠ wrote:

Seems that the debug avenue has been exhausted, short of running SFP.C in
debug mode.

You're saying you never see TX_FAULT asserted other than when the
interface is down?

There is still no explanation why the module passes the 300 ms deassert
TX_FAULT test most of the time but fails intermittently at other times,
being kind of incoherent. Maybe it is just wishful thinking but it seems a
bit far-fetched that the module is really causing this, least the readings
from GPIO do not provide any such indicator.

Could there be something choking / blocking the communication channel
between the module and the kernel, some kernel code getting stuck / leaked
in memory?

There is no "communication channel" involved here.  It is just those
GPIOs.

Could the ipupdown routine, which has its own implementation in OpenWrt, be
an interfering agent, e.g. the way it constructs or tears down the iif,
though I do not see how?

Very unlikely.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up