All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH] net: dsa: fix mv88e6xxx switches
Date: Sat, 23 Jan 2016 19:06:22 +0000	[thread overview]
Message-ID: <20160123190622.GA10826@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20160123181526.GD3880@lunn.ch>

On Sat, Jan 23, 2016 at 07:15:26PM +0100, Andrew Lunn wrote:
> Thanks for digging into this.

I hope you saw v2, which is functionally identical.

> I think this is a step towards a solution, but does not solve all the
> problems.
> 
> e.g. I have a switch interface lan0 with the IP address
> 192.168.10.2. I can ping this address from another host. I then take
> the IP address off the interface, create a br0 device, add lan0 to the
> bridge, and put 192.168.10.2 onto the bridge. I should be able to then
> ping the address. But it does not work.

That works for me.  Maybe it's differences in the switch device?  I
seem to remember you said your switch was an older generation than
mine (88E6176).

root@clearfog:~# brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.005043020202       no              lan1
                                                        lan2
                                                        lan3
                                                        lan4
                                                        lan5
                                                        lan6
root@clearfog:~# ip addr show|grep 192.168.254
root@clearfog:~# ip addr add 192.168.254.3/24 dev br0
root@clearfog:~# ping 192.168.254.2
PING 192.168.254.2 (192.168.254.2) 56(84) bytes of data.
64 bytes from 192.168.254.2: icmp_seq=1 ttl=255 time=0.648 ms
^C
--- 192.168.254.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.648/0.648/0.648/0.000 ms
root@clearfog:~# ip addr del 192.168.254.3/24 dev br0
root@clearfog:~# brctl delif br0 lan1
root@clearfog:~# ip addr add 192.168.254.3/24 dev lan1
root@clearfog:~# ping 192.168.254.2
PING 192.168.254.2 (192.168.254.2) 56(84) bytes of data.
64 bytes from 192.168.254.2: icmp_seq=1 ttl=255 time=0.331 ms
^C
--- 192.168.254.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.331/0.331/0.331/0.000 ms
root@clearfog:~# ip addr del 192.168.254.3/24 dev lan1
root@clearfog:~# brctl addif br0 lan1
root@clearfog:~# ip addr add 192.168.254.3/24 dev br0
root@clearfog:~# ping 192.168.254.2
PING 192.168.254.2 (192.168.254.2) 56(84) bytes of data.
64 bytes from 192.168.254.2: icmp_seq=1 ttl=255 time=0.630 ms
^C
--- 192.168.254.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.630/0.630/0.630/0.000 ms

I have no other patches for DSA other than the v2 I posted on this
kernel.

I'd suggest adding back the debugfs register dumping so you can get
some diagnostics, and work out what's different in the configuration
between a working kernel and a non-working kernel:

https://github.com/vivien/linux/commit/b23c6568011c84b80a8f5632ac819a5dbdca2dc1.patch

However, what I do notice is that trying to use vlans is a complete
fail - the switch strips _all_ vlan tags off the outgoing packets
no matter how I setup a vlan, whether it's on br0, or on a switch
port:

Packet as observed on a host connected to the switch port with no
vlan capability:
         0x0000:  ffff ffff ffff 0050 4302 0202 0806 0001
         0x0010:  0800 0604 0001 0050 4302 0202 c0a8 fe03 ...

Packet observed on Armada 388's eth interface connected to the 88E6176
switch:
         0x0000:  ffff ffff ffff 0050 4302 0202 dada 0000
         0x0010:  6030 0800 0806 0001 0800 0604 0001 0050 ...

The packet should appear on the wire with the 8100 0800 vlan protocol
ID + tag, but it appears with the vlan protocol and tag stripped.  So
there's yet more issues here.

Incoming packets from the interface appear to be dropped as far as I
can tell - the response to those ARP packets doesn't appear, though
I'm not convinced that I've been able to get the only vlan-capable
device on that side of the network to be setup correctly for vlans -
but obviously it's a total loss if vlan transmission isn't working.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2016-01-23 19:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-23 10:51 [PATCH] net: dsa: fix mv88e6xxx switches Russell King
2016-01-23 18:15 ` Andrew Lunn
2016-01-23 19:06   ` Russell King - ARM Linux [this message]
2016-01-23 19:37     ` Andrew Lunn
2016-01-23 19:48       ` Russell King - ARM Linux
2016-01-23 20:16         ` Andrew Lunn
2016-01-23 20:44           ` Russell King - ARM Linux
2016-01-23 22:12             ` Andrew Lunn
2016-01-23 22:23               ` Andrew Lunn
2016-01-23 23:31                 ` Russell King - ARM Linux
2016-01-24  6:01                   ` Vivien Didelot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160123190622.GA10826@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@savoirfairelinux.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.