Ethernet speed regression on ath79 -- additional tests useful

Hi all -

Today I reported a bug that has shown up in 21.02.0 that limits the uplink port of at least two different ath79 devices to 100Mbps (when it should be gigabit).

Here is my thread, and another one that is likely related.

I have a theory that this affects only devices that have a separate ethernet port for uplink (i.e. not a port on the same switch as the LAN). In the case of the RouterStation Pro, it has a 3-port switch on eth1 and a separate single ethernet uplink port on eth0. The Buffalo router that is in the second thread has a similar arrangement (although the uplink appears to be on eth1).

It would be really handy if other similar ath79 based devices could be tested to see if this behavior appears to be consistent across other hardware. It could provide additional insight to help the developers identify the root cause (i.e. 1 or more commits that likely caused this regression).

Thanks!

Just a quick bump and question...

I filed the bug a bit over 2 weeks ago. In that time, I've done some searches on the commits to the ath79 platform since 19.07.x, but I haven't been able to turn up anything that seems to apply to this situation, although I'm happy to look some more if anyone has any pointers.

The bug itself doesn't appear to have been reviewed yet (it has not been confirmed or assigned). I suspect/hope that it is a relatively simple issue, but I am aware that it is probably considered low priority and low severity. Is there anything that I can do that might help get this through the bug triage process? For example, is there any additional data I can provide or any other info that might be useful to the dev team?

Thanks!

I have good news about this bug: @dreamlayers found a commit that appears to resolve this bug. Details here and in the bug report.

How do we get this bug and commit surfaced for the dev team to review and hopefully merge into 21.02.1?

1 Like

You author a pull request at https://github.com/openwrt/openwrt/pulls
Should be straightforward, if it is about a cherry pick.
The original bug fix commit 766e0f584a32 in master seems to have been made by @blocktrron , so he might be persuaded to backport it even without a PR.

1 Like

Sounds good. If @blocktrron sees this and takes care of the back port, that would be awesome. Otherwise, I'll do that PR.

Meanwhile, @blocktrron -- thanks for the bug fix and thanks*100 in advance if you are able to back port it. Let me know if you need any additional info or testing on this one or if you need me to do anything to help out in any way.

1 Like

I've picked the fix to 21.02. Not sure why i did not so this back when originally adding it to master.

1 Like

So is it all good now (for 21.02.1) or is there anything left to do?

tidying up, closing the bug, marking threads as solved, etc.

:slight_smile:
Yes, I am actually aiming to do that. .

What I meant by "anything left to do?" was simply with respect to getting the commit merged into the 21.02 branch so it will appear in 21.02.1. Assuming that's all good now, I can indeed close these threads.

That said, in the bug itself, I see a "request closure" button -- should this be done now, or is the convention to wait until 21.02.1 with the fix in place and in the stable release build to close the bug?

You can request bug closure now.

The cherry pick commit is there in the 21.02 branch (like blocktrron said), and you can reference to that.
See 21.02 log in

1 Like

Awesome. Sorry if I've been a bit dense here -- just wanted to make sure I'm following all the right protocols for closure on the bug reporting side of the house. Closure is now requested.