Hi Peter
> Maybe I can get some information from our support if
> DSA_TAG_PROTO_EDSA is supported for the port config (0x4) register
> on the 6341 switch after all or if it should be omitted.
It would be nice to hear what Marvell says about this. It does seem an
odd thing to remove, so it could b
On Tue, Dec 01, 2020 at 09:49, Peter Vollmer wrote:
> On Thu, Nov 26, 2020 at 10:41:44PM +0100, Tobias Waldekranz wrote:
>> On Wed, Nov 25, 2020 at 15:09, Peter Vollmer wrote:
>> > - pinging from client0 (connected to lan0 ) to the bridge IP, the ping
>> > requests (only the requests) are also se
On Thu, Nov 26, 2020 at 11:23:59PM +0100, Andrew Lunn wrote:
> > > I tested setting .tag_protocol=DSA_TAG_PROTO_DSA for the 6341 switch
> > > instead, resulting in a register setting of 04 Port control for port 5
> > > = 0x053f (i.e. EgressMode=Unmodified mode, frames are transmitted
> > > unmodifi
On Thu, Nov 26, 2020 at 10:41:44PM +0100, Tobias Waldekranz wrote:
> On Wed, Nov 25, 2020 at 15:09, Peter Vollmer wrote:
> > - pinging from client0 (connected to lan0 ) to the bridge IP, the ping
> > requests (only the requests) are also seen on client1 connected to
> > lan1
>
> This is the expec
> > I tested setting .tag_protocol=DSA_TAG_PROTO_DSA for the 6341 switch
> > instead, resulting in a register setting of 04 Port control for port 5
> > = 0x053f (i.e. EgressMode=Unmodified mode, frames are transmitted
> > unmodified), which looks correct to me. It does not fix the above
> > problem
On Wed, Nov 25, 2020 at 15:09, Peter Vollmer wrote:
> Hi,
> I am still investigating the leaking packets problem we are having
> with a setup of an armada-3720 SOC and a 88E6341 switch ( connected
> via cpu port 5 , SGMII ,C_MODE=0xB, 2500 BASE-x). I now jumped to the
> net-next kernel (5.10.0-rc4
Hi,
I am still investigating the leaking packets problem we are having
with a setup of an armada-3720 SOC and a 88E6341 switch ( connected
via cpu port 5 , SGMII ,C_MODE=0xB, 2500 BASE-x). I now jumped to the
net-next kernel (5.10.0-rc4) and can now use the nice mv88e6xxx_dump
tool for switch regis
On Wed, Sep 30, 2020 at 09:19:56PM +0200, Andrew Lunn wrote:
> > What would be the best way to debug this ? Is there a way to dump the
> > ATU MAC tables to see what's going on with the address learning ?
>
> If you jump to net-next, and use
>
> https://github.com/lunn/mv88e6xxx_dump
>
> You can
> What would be the best way to debug this ? Is there a way to dump the
> ATU MAC tables to see what's going on with the address learning ?
If you jump to net-next, and use
https://github.com/lunn/mv88e6xxx_dump
You can dump the full ATU from the switch.
bridge fdb show
can give you some idea
On Wed, Sep 30, 2020 at 01:28:35PM +0300, Vladimir Oltean wrote:
> On Wed, Sep 30, 2020 at 12:09:03PM +0200, Peter Vollmer wrote:
> > lan0..lan3 are members of the br0 bridge interface.
>
> and so is eth0, I assume?
No, eth0 is a dedicated interface with its own IP. We have routing between eth0
a
On Wed, Sep 30, 2020 at 12:09:03PM +0200, Peter Vollmer wrote:
> lan0..lan3 are members of the br0 bridge interface.
and so is eth0, I assume?
> The problem is that for ICMP ping lan0-> eth0, ICMP ping request
> packets are leaking (i.e. flooded) to all other ports lan1..lan3,
> while the ping r
Hi all,
I am currently investigating a leaking packets problem on a
armada-37xx + MV88E6341 switch (via SGMII) + MV88E1512 Phy (via
RGMII) platform. We are using the mainline 5.4.y kernel.
The switch and phy setup is defined in the flat device tree as follows:
ð0 {
phy-mode = "rgmii-id"
12 matches
Mail list logo
