Messages in this thread | | | Date | Tue, 31 Oct 2023 18:34:39 +0200 | From | Vladimir Oltean <> | Subject | Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size |
| |
On Tue, Oct 31, 2023 at 03:16:50PM +0100, Linus Walleij wrote: > On Tue, Oct 31, 2023 at 12:33 AM Vladimir Oltean <olteanv@gmail.com> wrote: > > On Mon, Oct 30, 2023 at 11:57:33PM +0100, Linus Walleij wrote: > > > Here you can incidentally also see what happens if we don't pad the big packets: > > > the packet gets truncated. > > > > Are we sure we are debugging a switch problem? On how many platforms > > with the RTL8366RB can the issue be seen? Is the conduit interface the > > same on all these platforms, or is it different and that makes no > > difference? > > I don't have any other RTL8366RB systems than the D-Link DIR-685. > > I however have several systems with the same backing ethernet controller > connected directly to a PHY and they all work fine. > > Yours, > Linus Walleij
Ok, so we don't have a confirmation of breakage with other conduit interface than the Gemini driver, either. So a problem there is still not off the table.
So on the gemini-dlink-dir-685.dts platform, you can also use &gmac1 as a plain Ethernet port, right?
If possible, could you set up dsa_loop (enable CONFIG_NET_DSA_LOOP, replace "eth0" in dsa_loop_pdata with the netdev name of &gmac1, replace DSA_TAG_PROTO_NONE in dsa_loop_get_protocol() with your tagging protocol) and put a tcpdump on the remote end of the gmac1 port, to see if the issue isn't, in fact, somewhere else, maybe gmac_start_xmit()?
With dsa_loop, you turn &gmac1 into a conduit interface of sorts, except for the fact that there is no switch to process the DSA-tagged packets, you see those packets on the remote end, and you can investigate there whether it's the switch who's corrupting/truncating, or if they're somehow sent corrupted/truncated by Gemini on the wire (which would not be visible in a local tcpdump).
| |