I just updated my Unifi 6 Lite APs and became aware of this:
What??? There is absolutely no proof that this is a generic MT7621 bug. There are MT7621 device where EEE works just fine. Or at least it used to work before you deliberately broke it.
You had a perfectly fine workaround in userspace, where eee could simply be disabled by default on any affected device. But you still decided to not only force the default on everyone, but also remove our ability to re-enable EEE. Why?
This is a REAL bug:
root@u6-1:~# ethtool --show-eee lan
EEE Settings for lan:
EEE status: enabled - inactive
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: Not reported
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full
You're right, of course. Which means that I have to wait some time before I do that. Ignorance frustrates me. And the lack of interest for other use cases than "my own" is disrespectful. Trying to fake some polite respectful request to fix the fallout is hard.
That's very interesting, and explains why I've never seen the issue. Don't think I have any device which supports 10 Mbit/s eee. Must be rare? Anyway, that must be possible to work around in a driver. Couldn't it just mask the 10 Mbit/s link partner capability?
I, personally, haven't seen any EEE issues with 24.10 either, and I have multiple MT7621 devices in use. I knew of the reported issues before I switched my devices to 24.10, and I did make sure to enable EEE on both sides, in order to verify whether I'm affected. Looks like I'm not.
However, I'm using 1GBE exclusively, and from what I could gather off all the issue reports on GH and here in the forums, the port flapping, or that the port doesn't come up at all, happens a lot when the link partner is 100M or slower, and not so often in pure GBE environments. [Edit] I'm also undoing the gmac1-to-WAN muxing for all my builds (since I personally consider it "deliberate breakage of the switch functionality"), which likely explains why I'm not affected by the reported WAN port flapping, while many users of out-of-the-box 24.10 are.
Given that:
A lot of people are affected by the port flapping/failures in 24.10, where EEE for MT7530 got enabled out-of-the-box
Mediatek have recommended to disable EEE on MT7530 anyway
EEE is apparently still disabled in the Mediatek driver, it only gets erroneously(?) re-enabled later in recent kernels (see commit message)
With these conditions, hard-disabling EEE in DT should in fact be the easiest fix, and the safest bet for most users, making 24.10+ work again out of the box for every MT7621 user.
Understandably, users who are not affected (like you, me, ...) aren't too happy with the feature removal. We, however, are building our images ourselves anyway, right? So we can always revert the commit in question for our personal builds.
I don't see an issue with this change, in my opinion it fixes more than it breaks.
"a lot of people" and some Mediatek developer believes that EEE should be disabled for everyone else. Why should I care?
I don't. I care about facts and fixes.
That's a strange way to read that. How about trying to co-operate instead of making such unjustified accusations?
All proposals I have seen so far seem to involve different ways of deliberate breakage. You may of course refer to those as "patches". But you can't expect stuff like that to be accepted.
Can we please discuss fixes instead?
I can't handle this level of stupity and arrogance.
Why would I want to discuss the level of breakage? That's irrelevant. A bug needs a fix, not a replacement bug. Every use case counts. We need to FIX stuff, not jump back and forth between different kind of breakages - arguing about which is least bad. I don't care.
We are now in a situation where it is impossible to enable EEE on MT7621. That's unacceptable.
Great idea, but should some of the smaller flash devices be given this option, for example some of the 16M NAND devices do not need this.
Can there be an enablement of EEE option in the imagebuilder for MT7621 devices, like the ath ct and ath non-ct drivers for WiFi?
I've also seen people claim this affects filogic devices with MT7530 but no proof so far.
This is done on the recommendation of Mediatek, as you'll see if you read the comments on the commit. I doubt any of the OpenWrt devs know better than the vendor, but maybe you do?
I'm one of the many people who experienced connection flopping to a Nokia ONT that provides my fibre internet, so this is a real problem.
There are also other problems with default enabling EEE on MT7621 devices in 24.10. Notably the MT ethernet driver does not implement EEE controls, and so e.g. ER-X (which routes gmac1 to eth0) advertises EEE on eth0, with absolutely no way to control it or read back the state.
FYI - I found 10Mbps “green” Ethernet is the default config and wake state of most consumer PCs if they support power management or low power mode. Usually controllable by the driver, but still the default initial wake or sleep state.
You are obviously not aware of the history here. It was not Mediatek who enabled us to use the mainline mt7530 DSA and mtk_eth_soc drivers for MT7621. They thought it was a terrible idea. We didn't care:
Do you seriously think we should have listened to Mediatek and still used the out-of-tree drivers without DSA on the MT7621?
I do not doubt that Mediatek knows of hardware bugs related to EEE on the MT7621. But I don't expect them to ut any resources into solving that. Which is why they don't necessarily have the best solution to the issue.
I do not doubt that at all. At the same time it is a fact that MT7621 can work with EEE enabled under other conditions. This means that we do need a workaround for the issues. But I do not understand why it can't be made conditional on whatever triggers it. Or the other way around - disabled in safe environments.
But the 10Base-Te enabling part of the code is limited to the "YUKON-2 Optima Prime" chip, so I don't know how easy it will be locating the correct NIC.
