Re: [PATCH] net: dsa: qca8k: Disable mgmt Ethernet for qca8327
Michał Kępień <[email protected]>
| Newsgroups | org.kernel.vger.netdev,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Andrew, First of all, after taking a closer look at this issue and the driver code, I realized that the approach I went with in the patch stemmed from my ignorance and that I submitted it too quickly - apologies about that. > > While the qca8327 switch appears to support in-band mgmt Ethernet, > > prolonged use of that protocol (e.g. for polling link state) makes the > > device unstable: within minutes, ports randomly go down and no traffic > > is forwarded anymore. The same issues do not occur when MDIO is used > > exclusively, so ensure mgmt Ethernet is not used on the qca8327. > > Do you have time to narrow down the cause? Sure, I should be able to spare a few cycles on this in the upcoming weeks. > I _think_ in band management is used for a few different > things. e.g. statistics, as you said, PHY polling etc. Rather than > turning everything off, could you try just doing PHY polling via MDIO, > but statistics via ethernet, and do an ethtool -S every so often to > see if you can trigger the problem. Ack, I'll try that. > Could you also check if the management packets are getting lost? Look > at the results from wait_for_completion_timeout(), is it timing out? Ack. > If so, is the retry mechanism working? When i added the Marvell > equivalent for in-band signalling i got the retry mechanism wrong, but > never noticed because i was not loosing packets. Could you please point me at the exact retry mechanism you had in mind, either the qca8k one or the Marvell equivalent? I cannot see any in drivers/net/dsa/qca/qca8k-8xxx.c. If I'm reading qca8k code correctly, when wait_for_completion_timeout() fails, its return value is just bubbled up the call chain. Thanks, -- Best regards, Michał Kępień