FS#3832 - [Regression] xrx200 switch affecting AVM Fritz!Box 7362SL #8833
Comments
|
Hauke: Is a linkup or anything detected when you connect or disconnect the Ethernet cable? Could you please post the output of these files from the working version and the broken version: |
|
MPW: 19.07.7 (working):
21.02.0-rc1 (not working):
I also looked into the git history. Maybe this commit has something to do with the regression: |
|
MPW: Oh, just saw, forgot to answer your question: The physical link (layer-1) is there. If I connect port 3 or 4 to a switch, it shows me 100 Mbit/s. |
|
skleeschulte: I can add this information: When I connect a 100baseT-only device to LAN port 3 or 4, everything works as expected. When I connect a 1000baseT capable device, that device's ethernet port shows it is working in 100baseT mode; however, the port status on page /cgi-bin/luci/admin/network/switch shows "1000baseT full-duplex". Is anyone working on this issue? What would be the next step to do? |
|
Hauke: Is the traffic working like expected and the only problem you see is that the wrong mode, "1000baseT full-duplex" instead of "100baseT full-duplex" is shown in LuCI? Could you please provide the output of "ethtool " for both cases and the output of this command: "ubus call network.device status". |
|
Martinius: Hi I can confirm this behavior. The ports are not working, only the first and second ethernet port are working. Here is also a link to a thread were other users confirm that after the upgrade the ports appear to be dead. https://forum.openwrt.org/t/fritzbox-7362-sl-openwrt-port/28187/38 If it helps my output for "ubus call network.device status" is:
|
|
skleeschulte: To clarify: LAN ports 3 and 4 only work correctly, when not connected or connected to a 100baseT-only device. In this case, the port status on page /cgi-bin/luci/admin/network/switch is correct and network connectivity works as expected. As soon as at least one 1000baseT-capable device is connected to port 3 or 4, both ports (3 and 4) stop working. |
|
skleeschulte: Here are the outputs of "ethtool " and "ubus call network.device status" for both cases: With a 100baseT-only device connected to LAN port 3 and port 4 unconnected:
With a 1000baseT-capable device connected to LAN port 3 and port 4 unconnected:
|
|
nicefile: some tests on FB7362 OpenWrt SNAPSHOT, r18460-def9565be6 OpenWrt SNAPSHOT, r17180-089c2bb217 root@OpenWrt:~# logread |grep lan4 |
|
Martinius: Could we mark this as confirmed? |
|
Kestrel discovered that the wrong reset pin numbers were probably to blame. It would be good if someone could verify this on his device. |
|
@skleeschulte @nicefile Hi, since I do not own the device, can you try changing the GPIO reset pin in the vr9_avm_fritz736x.dtsi from 37 to 45 and see if that solves the issue with the ports? |
|
@kestrel1974 nothing changed here . lan3 and4 is up /down all the time with 10/100 or 1Gbit client. With 100Mbit client I'm able to even ssh to router but still flapping .7362SL tested |
|
@nicefile To bad, I cannot see anything else that differs. |
|
@nicefile Can you change the 37 to 45 here too and give it another try? Edit1: 37 to 45 please. |
|
@kestrel1974 no cigar .Exactly like described before . This might be something that came with linux-5.4 . On snapshot c331932 @5.4.69 version lan3&4 work only with 100Mbit client but same snapshot @4.19.138 lan3&4 work with 1Gbit client . |
|
@nicefile Which device model do you have exactly? |
|
What does "flapping" mean in this context? |
|
@skleeschulte lan3 and lan4 device link goes up and down in circle . Visible in logs clearly . |
|
@abajk There are traces in the web, that the 7362 SL (1und1) has the internal ports (1 + 2) as Gigabit and the external ports (3 + 4) as Fast ethernet only. Would that combination work? Is there any chance that based on the current device tree, that it is tried to set ports 3 + 4 to gigabit ethernet and as such the repeated turn it on, turn it off occurs? gswip_phy_link_up is externalized through dsa switch ops. I wonder if the caller uses SPEED_1000 as parameter for the two RMII ports because the speed register of the at803x.c query returns AT803X_SS_SPEED_1000 for ports 3 + 4? The avm stock firmware config sets ports 3 + 4 to MAC_RMII and it seems its just setting the flags without querying the bits from the phy, there is just two devices that set MAC_MODE_AUTO, so I guess the hard coded setting applies. But I dont own the device. I wonder if @nicefile could add "case SPEED_1000:" before this line and post back what the result is. I assume this would limit all ports to 100MBit or Fast Ethernet, but maybe the flapping goes away. Its a lot of speculation on my end. Maybe case SPEED_1000: needs to add a check if phy interface mode is RMII and then not set to 1G? |
|
@kestrel1974 . Hardware is like described internal lantiq 1Gb phy for port 1 + 2 and external (AR8030) FE phy for 3 + 4. Others reported that luci shows 1Gbit on port 3 + 4 .And ethtool shows supported and advertised on 10/100 level Also with 1Gb clients . I can test any idea but is it possible to paste modified part here or patch file ? pull 3085 to DSA drivers definitely broke something even if 1Gb clients didn't work before merge on ports 3 +4 |
|
@nicefile Please copy the attached file to target/linux/lantiq/patches-5.10, rename it to .patch plus change the two occurances of 37 in the vr9_avm_fritz7362sl.dts and then do a build and test it. My guess is that in some register Gigabit ethernet bit is set, which results in trying to set the gigabit configuration in mac up. Lets see if thats a match. |
|
@kestrel1974 still getting up and down on ports 3 & 4 with 100Mb client . I've double checked the both changes to dtsi and lantiq_gswip.c . |
|
@nicefile Thanks for testing. Then its probably something more difficult. I guess that the issue is dependent on the fact that for port 3+4 to be Gigabit ports they need external phys, which are not present at the 7362 sl. It could also be something in the at803x.c driver. |
|
@nicefile I have created a patch (based on 5.10.100 which hopefully also works with your 5.10 kernel version) that brings you back the at803x.c phy of the kernel 4.19. I have tested it and it works even on the 7490. It would be great if you can test it, please remove the other patch I sent you. |
|
@nicefile thanks, this confirms that the regulator code in please remove the |
|
@xdarklight so with 100Mbit client connected on boot i have random UP/DOWN events and traffic in up state is visible (RX/TX packets counts). But after a while longer period of UP is visible but no traffic . Then UP/DOWN events start kicking again but with no traffic. |
|
@nicefile thanks, that means hard resetting the PHY is not the cause of the up/down cycling issue. Between 4.14 and 5.4 one of the differences is that the PHY is not soft reset anymore unless there's a .soft_reset callback configured. The following patch (to be placed in Another observation I made is that AVM uses a 10ms delay after changing the GPIO's reset line. We can do the same with the following patch (applied directly against the OpenWrt tree): vr9_avm_fritz736xsl-add-reset-delays.patch Please test the patches individually and by removing any previous patches/changes. PS: These steps also apply to the 7360 SL if anyone wants to test on that board. |
|
@kestrel1974 thank You for your patches. So I have tested them both in separate builds and guess what ? no change in behaviour . In previous test I've checked that DSA driver support caused UP/DOWN loop and migration from 4.19 to 5.4 killed media sense for ar8030 PHY . Is it possible to keep DSA for ports 1&2 and swconfig for 3&4 ? |
that's unfortunate, still thank you for testing and reporting back!
huh, let me mention my interepretation of the problem we're looking at to make sure that there's no misunderstanding. My understanding is that LAN 3 and 4 are cycling between link UP/DOWN since OpenWrt 21.02. What do you mean with "migration from 4.19 to 5.4 killed media sense for ar8030 PHY"? |
I do not see any UP/DOWN Spam in my kernel log. It registers a link on the ports, but there is not traffic possible (No ping/ DHCP from or to connected devices). Here is the relevant kernel log when connecting and disconnecting devices to the ports:
I run the vanilla OpenWrt 21.02 with no patches. For completeness here is my boot log (no devices connected to Lan port 3 and 4): |
Thanks! This at confirms that at least the symptoms are different between the GSWIP and swconfig based drivers. To anyone who is still interested: the following patch would affect both, 7360 SL and 7362 SL: |
This patch makes LAN3 and LAN4 work on my 7362 SL! |
That's awesome! I will send this patch upstream later and mark it for backporting to stable kernels (5.10 and 5.15). |
|
@jospezial also reported LAN port instability issues on VGV7510KW22. This router uses an IC+ IP101A chip connected via the RMII interface. Maybe Martin's patch will fix this issue too. |
just to manage hopes and dreams: I think this patch is unrelated to issues on VGV7510KW22 because If it the board was wired for MII instead of RMII then I think no traffic would flow at all. |
You are right. I looked in the wrong file. |
|
|
@xdarklight I can also confirm this patch work on my 7362SL with 100Mbit and 1Gb client . Hope to see it soon in master branch. |
|
On Mon, 25 Apr 2022 15:56:03 +0000 (UTC) nicefile ***@***.***> wrote:
@xdarklight I can also confirm this patch work on my 7362SL with 100Mbit and 1Gb client . Hope to see it soon in master branch.
I am oh so happy. @xdarklight THANK YOU!
@NiceLife, can you please send me a howto to use this patch, please?
thanks a lot.
…--
whoami ***@***.***>
|
|
First step would be rename the patch to remove the .txt extension. |
Thanks for confirming this! Once the patch is accepted upstream (in the The benefit of this approach: the fix will show up in master but also also in the 22.03 branch. If anyone really needs this sooner then please wait until the patch has been accepted in |
@xdarklight thanks a LOT for a much anticipated fix. We're all very grateful to you. @nicefile , can you please help me get my hands on this, an howto, use the patch would be great. I can't wait any longer for it to be taken up upstream. Please help. And thanks a lot. |
@xdarklight Confirmed, your patch works on latest LAN 1 & 2 and LAN 3 & 4 seem to report correct link speeds (I was plugging ethernet cable back and forth) bootlog |
@bananos , for those of us not familiar with obtaining the firmware outside the regular release channel, would you please say how to obtain and install the 'latest master' you mentioned, please? Thanks a lot! |
|
@allhailCdosdude Basically, to build OpenWRT image yourself you just need to follow this guide https://openwrt.org/docs/guide-developer/toolchain/use-buildsystem Below are a short version of the steps I've done to get my image on |
|
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71cffebf6358a7f5031f5b208bbdc1cb4db6e539 has just landed in mainline which is the fix for this issue. |
|
Can someone please test #9859 and provide the Tested-by there? |
|
On Mon, 25 Apr 2022 11:27:28 -0700 Martin Blumenstingl ***@***.***> wrote:
Thanks for confirming this!
Once the patch is accepted upstream (in the `net.git` tree) it'll take approx. one week to get into mainline.
From there it'll typically take one more week to show up in the next stable release.
And from then on it typically takes a few days to get that stable release into OpenWrt.
The benefit of this approach: the fix will show up in master but also also in the 22.03 branch.
If anyone really needs this sooner then please wait until the patch has been accepted in `net.git` and then backport it to OpenWrt yourself.
Any update on this, as to when it will be released, formally on OpenWrt, for those of us who do not have the skills to backport?
Thanks a lot! And a lovely day.
…--
whoami ***@***.***>
|
|
Fixed with 8592df6 |
|
On Mon, 16 May 2022 12:15:37 -0700 Martin Blumenstingl ***@***.***> wrote:
Fixed with 8592df6
The next **development snapshot** build (assuming this build hasn't started yet) will include the fix: https://downloads.openwrt.org/snapshots/targets/lantiq/xrx200/
Thanks a lot for the update, which came on 16 May. The next day, May 17, is the latest file from the link you provided. Hard to tell if the fix is included in the latest file from the link above. Anyone care to chance an answer, please?
Thanks a lot!
…--
whoami ***@***.***>
|
|
On this page you can view which commit was used during the last build by buildbot. In the case of the xrx200 target, it was this commit. This means that the fixes for Fritzbox 736x should already be included in these images. |
MPW:
The 7362sl by AVM has two gigabit ports labeled 1+2 and two fast ethernet ports labled 3+4.
They all used to work, but with OpenWrt 21.02.0 only the two gigabit ports work. Port 3+4 are dead. Linked (layer1) can be established, no layer2 or higher traffic possible.
OpenWrt 19.07.7 Kernel 4.14.221 supports ports 3 + 4
Openwrt 21.02.0-rc1 Kernel 5.4.111 ports 3 + 4 are dead
Notably might be the line ”failed to get the PCIe PHY“ which does not appear in 19.07.7.
As I didn't notice any changes regarding this particular device model, it might be a problem with the kernel driver for the switch module.
The text was updated successfully, but these errors were encountered: