The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---Am 25. Januar 2025 08:52:39 MEZ schrieb "Chester A. Unal" <chester.a.u...@arinc9.com>: >On 24/01/2025 23:43, Daniel Golle wrote: >> On Fri, Jan 24, 2025 at 11:03:28PM +0000, Chester A. Unal wrote: >>> On 24/01/2025 22:15, Hauke Mehrtens wrote: >>>>> @arinc9: >>>>>> >>>>>> Currently we have the following known bugs: >>>>>> >>>>>> [...] >>>>>> * Ethernet link unstable on some mt7530 switches. Deactivate EEE >>>>>> (Energy-Efficient Ethernet) as a workaround, see: >>>>>> https://github.com/openwrt/openwrt/issues/17351 >>>>> >>>>> Any idea what could be going on there? >>> >>> Here are the facts to consider: >>> >>> We have only started receiving reports of the unstable link issue with the >>> 24.10 branch. >>> >>> I believe the MT753X DSA subdriver did not receive changes in years with >>> regards to EEE or any other parts of the code that would cause link >>> instability. I am giving this opinion as a maintainer of the said >>> subdriver. >>> >>> There's a report by Florian [1], stating that the same issue appears with a >>> PHY that is not part of the MT7530 switch hardware. So the issue is >>> apparent on a system that does not have the MT7530 switch involved, and the >>> only common part of the reports is the MediaTek Ethernet driver. >> >> Thanks for the quick summary. >> >> Note that regarding Florian's report, on the WAX206 the RTL8221B-BV-VG >> PHY is connected to port 5 of the MT7531AE switch [1] and hence NOT to the >> MAC of MT7622 SoC. So it can of course still be an issue with that PHY >> (which has been giving us some trouble in general), but I'd be very >> confused if you insist that it would be caused by mtk_eth_soc, and would >> ask you to explain why you think that would be the case. > >Good point. I meant to say that the issue is apparent without the use of >the MT7530 switch PHYs. But as the switch MACs are still in use, we can't >completely factor out MT7530 and, therefore, the MT753X DSA subdriver. > >My suspicion had been the EEE operation on the link between the switch >(operating as a PHY) and the MediaTek SoC MAC, controlled by the MediaTek >Ethernet driver. But the switch PHY in question is a simple digital logic >to deliver only the basic functions of a link and is not conformant to the >IEEE Std 802.3-2022 so I don't expect EEE to be available at all on that >link. > >As all the reports involve the MT7530 switch MACs, the MediaTek Ethernet >driver must be irrelevant to this specific unstable link issue. > >It could be a race condition issue that existed since the EEE support was >brought to the MT753X DSA subdriver and became more noticeable with newer >kernels as things slow down. Remember the PHY initialisation issue that was >experienced heavily on the TP-Link devices with the MT7621 SoC? We solved >it by ensuring the switch as a PHY is initialised first, then the switch >PHYs. It could be a similar case. > >Chester A. > >_______________________________________________ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/mailman/listinfo/openwrt-devel Hello arinc9, sorry to bother you with this again. The WAX206 issue with it's Realtek WAN PHY has long been resolved but the mt7621-ramips plattform is still causing issues for users on the new release due to unstable/sometimes not working ethernet link. matjon just put some effort into debugging this (to some degree) <https://github.com/openwrt/openwrt/issues/17351#issuecomment-2798953937> And HanabishiRecca noticed that EEE somehow gets enabled even when the receiving side has it disabled. <https://github.com/openwrt/openwrt/issues/17351#issuecomment-2799921359> Do their posts somehow shine a different light on the matter or do you have an idea what could be at fault? Does EEE itself work fine but gets enabled when it shouldn't be? I know you are maintaining only the mt7530 part and not all related code so I don't expect you to change anything upstream. Though your opinion on the matter would be very valuable to us here. :) Regards Djfe
--- End Message ---
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel