OpenWrt 24.10 release status

[Felix Baumann]

Am 25. Januar 2025 08:52:39 MEZ schrieb "Chester A. Unal" <chester.a.unal at 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 at 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