| Message ID | 1235991382.30736.62.camel@localhost.localdomain |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote:
> You should write 0x003E ... see attached patch
Ups, I see (from the thread) that you have already done/tried this...
Jesper Dangaard Brouer wrote: > On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote: > >> You should write 0x003E ... see attached patch > > Ups, I see (from the thread) that you have already done/tried this... > Yes, although I think it will need some work in the future (I've set it to 1000Mb connection, you said you used 100Mb, etc) Question: I'm testing this by trying a ping out of my box. Linux replies by sending an ARP packet out, and the destination replies with an ARP packet in. I can see from the ethtool stats that the reply packets get into lan1.1 (the physical port I'm using), but I don't see them get moved through the CPU port. My understanding is that this should work via the VLAN map? I checked that setup and it looks OK. Any ideas where this might be going wrong? Thanks
Gary Thomas wrote: > Jesper Dangaard Brouer wrote: >> On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote: >> >>> You should write 0x003E ... see attached patch >> Ups, I see (from the thread) that you have already done/tried this... >> > > Yes, although I think it will need some work in the future > (I've set it to 1000Mb connection, you said you used 100Mb, etc) > > Question: I'm testing this by trying a ping out of my box. > Linux replies by sending an ARP packet out, and the destination > replies with an ARP packet in. I can see from the ethtool stats > that the reply packets get into lan1.1 (the physical port I'm > using), but I don't see them get moved through the CPU port. > My understanding is that this should work via the VLAN map? > I checked that setup and it looks OK. > > Any ideas where this might be going wrong? I also just noticed that the ESA registers (Global 1,2,3) aren't set at all. I'm pretty sure that the way I'm using the switch in my bootloader this doesn't matter as all packets have a fixed routing and the ESA recognition happens at the actual ethernet device. Is this going to cause problems with the VLAN (+DSA) based routing?
On Mon, 2 Mar 2009, Gary Thomas wrote: > Gary Thomas wrote: >> Jesper Dangaard Brouer wrote: >>> On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote: >>> >>>> You should write 0x003E ... see attached patch >>> Ups, I see (from the thread) that you have already done/tried this... >>> >> >> Yes, although I think it will need some work in the future >> (I've set it to 1000Mb connection, you said you used 100Mb, etc) >> >> Question: I'm testing this by trying a ping out of my box. >> Linux replies by sending an ARP packet out, and the destination >> replies with an ARP packet in. I can see from the ethtool stats >> that the reply packets get into lan1.1 (the physical port I'm >> using), but I don't see them get moved through the CPU port. Well, thats a break through :-) If I understand you correctly, the destination host actually receives the ARP packet and responds with a packet. That should means that the outgoing DSA tagging is working. Although I'm not sure about the incomming... >> My understanding is that this should work via the VLAN map? I think that the "VLAN map/table" has gotten a wrong name as it does not really determine the VLANs, it only says who can talk to whom. The switch does support a real vlan setup, but its deactivated in Lennerts driver, as I guess he wants Linux to handle the VLANs. (I use the real VLAN setup extensively in my driver). >> I checked that setup and it looks OK. I have also checked the different registers setting, and things looks quite alright. Although I'm missing the register datasheets for the 6131 chip, I found that I only have part 1 of 3 crap... I did find that the 6095 and 6097 does differ in the way DSA handling is done, as the 6097 supports Ethertype DSA and 6095 don't. But the 6131 driver looks like it does the right thing for the 6095. >> Any ideas where this might be going wrong? Is lan1.1 up and have you given it an IP address? (could I get a 'ifconfig' output?) Are you sending packets with VLAN tags? > I also just noticed that the ESA registers (Global 1,2,3) > aren't set at all. I'm pretty sure that the way I'm using > the switch in my bootloader this doesn't matter as all packets > have a fixed routing and the ESA recognition happens at the > actual ethernet device. Don't think the switch needs a MAC address... > Is this going to cause problems with the VLAN (+DSA) based > routing? Don't think so... Hilsen Jesper Brouer -- ------------------------------------------------------------------- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk ------------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Jesper Dangaard Brouer wrote: > > > > On Mon, 2 Mar 2009, Gary Thomas wrote: > >> Gary Thomas wrote: >>> Jesper Dangaard Brouer wrote: >>>> On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote: >>>> >>>>> You should write 0x003E ... see attached patch >>>> Ups, I see (from the thread) that you have already done/tried this... >>>> >>> >>> Yes, although I think it will need some work in the future >>> (I've set it to 1000Mb connection, you said you used 100Mb, etc) >>> >>> Question: I'm testing this by trying a ping out of my box. >>> Linux replies by sending an ARP packet out, and the destination >>> replies with an ARP packet in. I can see from the ethtool stats >>> that the reply packets get into lan1.1 (the physical port I'm >>> using), but I don't see them get moved through the CPU port. > > Well, thats a break through :-) If I understand you correctly, the > destination host actually receives the ARP packet and responds with a > packet. > > That should means that the outgoing DSA tagging is working. Although > I'm not sure about the incomming... > >>> My understanding is that this should work via the VLAN map? > > I think that the "VLAN map/table" has gotten a wrong name as it does not > really determine the VLANs, it only says who can talk to whom. The > switch does support a real vlan setup, but its deactivated in Lennerts > driver, as I guess he wants Linux to handle the VLANs. (I use the real > VLAN setup extensively in my driver). I agree that the simple mode Lennert's code uses is not VLAN on the hardware, just internal switch path routes. >>> I checked that setup and it looks OK. > > I have also checked the different registers setting, and things looks > quite alright. Although I'm missing the register datasheets for the > 6131 chip, I found that I only have part 1 of 3 crap... > > I did find that the 6095 and 6097 does differ in the way DSA handling is > done, as the 6097 supports Ethertype DSA and 6095 don't. But the 6131 > driver looks like it does the right thing for the 6095. I didn't look at the 6097 yet, but I have scoured the 6095 and 6131 data sheets and I can't see what's wrong. The differences between these two parts are extremely minor - basically the number of ports and which one might be used for the CPU. > >>> Any ideas where this might be going wrong? > > Is lan1.1 up and have you given it an IP address? > (could I get a 'ifconfig' output?) Yes it's up. > Are you sending packets with VLAN tags? No VLAN tagging (by Linux), just normal IPv4 packets. Here's what I did: root@ppc_target:~ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:1D:11:81:00:00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1180 (1.1 KiB) TX bytes:1180 (1.1 KiB) Base address:0x6000 root@ppc_target:~ ifconfig lan1.1 192.168.12.188 up root@ppc_target:~ lan1.1: link up, 100 Mb/s, full duplex, flow control disabled root@ppc_target:~ ifconfig eth0 Link encap:Ethernet HWaddr 00:1D:11:81:00:00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1180 (1.1 KiB) TX bytes:1180 (1.1 KiB) Base address:0x6000 lan1.1 Link encap:Ethernet HWaddr 00:1D:11:81:00:00 inet addr:192.168.12.188 Bcast:192.168.12.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) root@ppc_target:~ ethtool -S lan1.1 NIC statistics: tx_packets: 0 tx_bytes: 0 rx_packets: 0 rx_bytes: 0 in_good_octets: 2096784 in_bad_octets: 0 in_unicast: 3601 in_broadcasts: 528 in_multicasts: 70 in_pause: 0 in_undersize: 0 in_fragments: 0 in_oversize: 0 in_jabber: 0 in_rx_error: 0 in_fcs_error: 0 out_octets: 230866 out_unicast: 3595 out_broadcasts: 3 out_multicasts: 0 out_pause: 0 excessive: 0 collisions: 0 deferred: 0 single: 0 multiple: 0 out_fcs_error: 0 late: 0 hist_64bytes: 3705 hist_65_127bytes: 326 hist_128_255bytes: 159 hist_256_511bytes: 15 hist_512_1023bytes: 3592 hist_1024_max_bytes: 0 root@ppc_target:~ ethtool -S lan1.8 mv88e6131_get_ethtool_stats(7) => CPU NIC statistics: tx_packets: 0 tx_bytes: 0 rx_packets: 0 rx_bytes: 0 in_good_octets: 232054 in_bad_octets: 0 in_unicast: 3595 in_broadcasts: 5 in_multicasts: 0 in_pause: 0 in_undersize: 0 in_fragments: 0 in_oversize: 0 in_jabber: 0 in_rx_error: 0 in_fcs_error: 0 out_octets: 2021576 out_unicast: 3599 out_broadcasts: 9 out_multicasts: 1 out_pause: 0 excessive: 0 collisions: 0 deferred: 0 single: 0 multiple: 0 out_fcs_error: 0 late: 0 hist_64bytes: 3600 hist_65_127bytes: 9 hist_128_255bytes: 0 hist_256_511bytes: 4 hist_512_1023bytes: 3596 hist_1024_max_bytes: 0 root@ppc_target:~ ping -c 5 192.168.12.18 PING 192.168.12.18 (192.168.12.18): 56 data bytes --- 192.168.12.18 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss root@ppc_target:~ ifconfig lan1.1 lan1.1 Link encap:Ethernet HWaddr 00:1D:11:81:00:00 inet addr:192.168.12.188 Bcast:192.168.12.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:252 (252.0 B) root@ppc_target:~ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:1D:11:81:00:00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1180 (1.1 KiB) TX bytes:1456 (1.4 KiB) Base address:0x6000 root@ppc_target:~ ethtool -S lan1.1 NIC statistics: tx_packets: 6 tx_bytes: 252 rx_packets: 0 rx_bytes: 0 in_good_octets: 2099816 in_bad_octets: 0 in_unicast: 3607 in_broadcasts: 542 in_multicasts: 71 in_pause: 0 in_undersize: 0 in_fragments: 0 in_oversize: 0 in_jabber: 0 in_rx_error: 0 in_fcs_error: 0 out_octets: 231250 out_unicast: 3595 out_broadcasts: 9 out_multicasts: 0 out_pause: 0 excessive: 0 collisions: 0 deferred: 0 single: 0 multiple: 0 out_fcs_error: 0 late: 0 hist_64bytes: 3718 hist_65_127bytes: 331 hist_128_255bytes: 168 hist_256_511bytes: 15 hist_512_1023bytes: 3592 hist_1024_max_bytes: 0 root@ppc_target:~ ethtool -S lan1.8 mv88e6131_get_ethtool_stats(7) => CPU NIC statistics: tx_packets: 0 tx_bytes: 0 rx_packets: 0 rx_bytes: 0 in_good_octets: 232438 in_bad_octets: 0 in_unicast: 3595 in_broadcasts: 11 in_multicasts: 0 in_pause: 0 in_undersize: 0 in_fragments: 0 in_oversize: 0 in_jabber: 0 in_rx_error: 0 in_fcs_error: 0 out_octets: 2021576 out_unicast: 3599 out_broadcasts: 9 out_multicasts: 1 out_pause: 0 excessive: 0 collisions: 0 deferred: 0 single: 0 multiple: 0 out_fcs_error: 0 late: 0 hist_64bytes: 3606 hist_65_127bytes: 9 hist_128_255bytes: 0 hist_256_511bytes: 4 hist_512_1023bytes: 3596 hist_1024_max_bytes: 0 You can see that lan1.1 "in_unicast" changed by 6 packets. These correspond to the ARP reply packets I see the destination host (192.168.12.18) send out. > >> I also just noticed that the ESA registers (Global 1,2,3) >> aren't set at all. I'm pretty sure that the way I'm using >> the switch in my bootloader this doesn't matter as all packets >> have a fixed routing and the ESA recognition happens at the >> actual ethernet device. > > Don't think the switch needs a MAC address... > >> Is this going to cause problems with the VLAN (+DSA) based >> routing? > > Don't think so... I added in the correct ESA on the switch and the lan1.1 incoming counters now track the unicode packets. Since I still can't get them through to the CPU port, I don't know if this was important. Any ideas how I might troubleshoot why packets that come into lan1.1 (port 0) aren't being pushed to the CPU port?
On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote: > Any ideas how I might troubleshoot why packets that come > into lan1.1 (port 0) aren't being pushed to the CPU port? The switch supports port monitoring, with seperate ingress and egress mapping, thus you could place another PC on another port and direct traffic towards that, and by tcpdump inspecting ingress and egress on the different physical ports... Thats how I debugged it once... I also used/implemented the VLAN violation interrupt, while I debugged the VLAN setup. The switch also have a ATU (MAC-table) violation interrupt, perhaps that might tell you something?
On Tue, 2009-03-03 at 09:52 +0100, Jesper Dangaard Brouer wrote: > On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote: > > Any ideas how I might troubleshoot why packets that come > > into lan1.1 (port 0) aren't being pushed to the CPU port? > > The switch supports port monitoring, with seperate ingress and egress > mapping, thus you could place another PC on another port and direct > traffic towards that, and by tcpdump inspecting ingress and egress on > the different physical ports... Thats how I debugged it once... > > I also used/implemented the VLAN violation interrupt, while I debugged > the VLAN setup. The switch also have a ATU (MAC-table) violation > interrupt, perhaps that might tell you something? Another thing... An IXP425 specific change I had to make, was to disable NPE_learning for the ixp400_eth driver. insmod ixp400_eth npe_learning=0 MODULE_PARM_DESC(npe_learning, "If non-zero, NPE MAC Address Learning & Filtering feature will be enabled"); Perhaps the GIANFAR driver also has this kind of MAC address filtering?
Jesper Dangaard Brouer wrote: > On Tue, 2009-03-03 at 09:52 +0100, Jesper Dangaard Brouer wrote: >> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote: >>> Any ideas how I might troubleshoot why packets that come >>> into lan1.1 (port 0) aren't being pushed to the CPU port? >> The switch supports port monitoring, with seperate ingress and egress >> mapping, thus you could place another PC on another port and direct >> traffic towards that, and by tcpdump inspecting ingress and egress on >> the different physical ports... Thats how I debugged it once... >> >> I also used/implemented the VLAN violation interrupt, while I debugged >> the VLAN setup. The switch also have a ATU (MAC-table) violation >> interrupt, perhaps that might tell you something? > > Another thing... An IXP425 specific change I had to make, was to disable > NPE_learning for the ixp400_eth driver. > > insmod ixp400_eth npe_learning=0 > > MODULE_PARM_DESC(npe_learning, "If non-zero, NPE MAC Address Learning & > Filtering feature will be enabled"); > > Perhaps the GIANFAR driver also has this kind of MAC address filtering? > I don't think this is a problem; no packets are getting [back] to the gianfar interface (based on RX interrupt counts)
Jesper Dangaard Brouer wrote: > On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote: >> Any ideas how I might troubleshoot why packets that come >> into lan1.1 (port 0) aren't being pushed to the CPU port? > > The switch supports port monitoring, with seperate ingress and egress > mapping, thus you could place another PC on another port and direct > traffic towards that, and by tcpdump inspecting ingress and egress on > the different physical ports... Thats how I debugged it once... I'm a bit fuzzy on this - could you explain in a bit more detail? > I also used/implemented the VLAN violation interrupt, while I debugged > the VLAN setup. The switch also have a ATU (MAC-table) violation > interrupt, perhaps that might tell you something? > Thanks
On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote: > Jesper Dangaard Brouer wrote: > > On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote: > >> Any ideas how I might troubleshoot why packets that come > >> into lan1.1 (port 0) aren't being pushed to the CPU port? > > > > The switch supports port monitoring, with seperate ingress and egress > > mapping, thus you could place another PC on another port and direct > > traffic towards that, and by tcpdump inspecting ingress and egress on > > the different physical ports... Thats how I debugged it once... > > I'm a bit fuzzy on this - could you explain in a bit more detail? You basically set the monitor destination port via REG_GLOBAL reg 0x1A "Monitor Control". /* Register: Monitor Control (0x1A) ------------------------- bit 15:12= Ingress Monitor Dest bit 11:8 = Egress Monitor Dest bit 7:4 = ARP Dest bit 3:0 = Reserved */ Then you configure the port register 0x08 "port control2", that this port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress. /* Register: Port Control 2 (0x8) ------------------------ bit 15 = IgnoreFSC: Force good FSC in frame bit 14 = VTU_prio_override : VTU setting overrides prio bit 13 = ATU_SA_prio_overrite: ATU SA setting overrides prio bit 12 = ATU_DA_prio_overrite: ATU DA setting overrides prio bit 11:10 = 802.1Q mode [00] = <Disabled>: use VLANtable only [01] = <Fallback>: fallback to VLANTable [10] = <Check> : drop on miss (eq. not in VTU) [11] = <Secure> : drop on miss and membership violation bit 9 = Discard Tagged bit 8 = Discard Untagged bit 7 = MapDA: Map using DA hits bit 6 = Default Forward (normal switch operation) bit 5 = Monitor egress bit 4 = Monitor ingress bit 3:0 = CPU port */ Reading through the "Monitor Control" register description, there is a interesting description about the "ARPdest" setting... Could you try to set it to the CPU port and see if that helps?
Jesper Dangaard Brouer wrote: > On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote: >> Jesper Dangaard Brouer wrote: >>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote: >>>> Any ideas how I might troubleshoot why packets that come >>>> into lan1.1 (port 0) aren't being pushed to the CPU port? >>> The switch supports port monitoring, with seperate ingress and egress >>> mapping, thus you could place another PC on another port and direct >>> traffic towards that, and by tcpdump inspecting ingress and egress on >>> the different physical ports... Thats how I debugged it once... >> I'm a bit fuzzy on this - could you explain in a bit more detail? > > You basically set the monitor destination port via REG_GLOBAL reg 0x1A > "Monitor Control". > > /* Register: Monitor Control (0x1A) > ------------------------- > bit 15:12= Ingress Monitor Dest > bit 11:8 = Egress Monitor Dest > bit 7:4 = ARP Dest > bit 3:0 = Reserved > */ > > Then you configure the port register 0x08 "port control2", that this > port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress. > > /* Register: Port Control 2 (0x8) > ------------------------ > bit 15 = IgnoreFSC: Force good FSC in frame > bit 14 = VTU_prio_override : VTU setting overrides prio > bit 13 = ATU_SA_prio_overrite: ATU SA setting overrides prio > bit 12 = ATU_DA_prio_overrite: ATU DA setting overrides prio > bit 11:10 = 802.1Q mode > [00] = <Disabled>: use VLANtable only > [01] = <Fallback>: fallback to VLANTable > [10] = <Check> : drop on miss (eq. not in VTU) > [11] = <Secure> : drop on miss and membership violation > bit 9 = Discard Tagged > bit 8 = Discard Untagged > bit 7 = MapDA: Map using DA hits > bit 6 = Default Forward (normal switch operation) > bit 5 = Monitor egress > bit 4 = Monitor ingress > bit 3:0 = CPU port > */ > > > Reading through the "Monitor Control" register description, there is a > interesting description about the "ARPdest" setting... Could you try to > set it to the CPU port and see if that helps? > It's already set this way (sans bits 4&5) REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0); I tried turning on bit 4 on port 0 (lan1.1). Now I can see what's coming into that port, but it doesn't look right: Here's the ARP going out: 13:46:29.348449 00:1d:11:81:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x4000), length 46: 0x0000: ffff ffff ffff 001d 1181 0000 4000 0000 0x0010: 0806 0001 0800 0604 0001 001d 1181 0000 0x0020: c0a8 0cbc 0000 0000 0000 c0a8 0c12 Here's the ARP reply coming back: 13:46:29.348907 00:1e:c9:2f:73:6c > 00:1d:11:81:00:00, ethertype Unknown (0x8004), length 64: 0x0000: 001d 1181 0000 001e c92f 736c 8004 0000 0x0010: 0806 0001 0800 0604 0002 001e c92f 736c 0x0020: c0a8 0c12 001d 1181 0000 c0a8 0cbc 0000 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 I understand the 0x4000 DSA tag going out, but what's the 0x8004?
Gary Thomas wrote: > Jesper Dangaard Brouer wrote: >> On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote: >>> Jesper Dangaard Brouer wrote: >>>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote: >>>>> Any ideas how I might troubleshoot why packets that come >>>>> into lan1.1 (port 0) aren't being pushed to the CPU port? >>>> The switch supports port monitoring, with seperate ingress and egress >>>> mapping, thus you could place another PC on another port and direct >>>> traffic towards that, and by tcpdump inspecting ingress and egress on >>>> the different physical ports... Thats how I debugged it once... >>> I'm a bit fuzzy on this - could you explain in a bit more detail? >> You basically set the monitor destination port via REG_GLOBAL reg 0x1A >> "Monitor Control". >> >> /* Register: Monitor Control (0x1A) >> ------------------------- >> bit 15:12= Ingress Monitor Dest >> bit 11:8 = Egress Monitor Dest >> bit 7:4 = ARP Dest >> bit 3:0 = Reserved >> */ >> >> Then you configure the port register 0x08 "port control2", that this >> port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress. >> >> /* Register: Port Control 2 (0x8) >> ------------------------ >> bit 15 = IgnoreFSC: Force good FSC in frame >> bit 14 = VTU_prio_override : VTU setting overrides prio >> bit 13 = ATU_SA_prio_overrite: ATU SA setting overrides prio >> bit 12 = ATU_DA_prio_overrite: ATU DA setting overrides prio >> bit 11:10 = 802.1Q mode >> [00] = <Disabled>: use VLANtable only >> [01] = <Fallback>: fallback to VLANTable >> [10] = <Check> : drop on miss (eq. not in VTU) >> [11] = <Secure> : drop on miss and membership violation >> bit 9 = Discard Tagged >> bit 8 = Discard Untagged >> bit 7 = MapDA: Map using DA hits >> bit 6 = Default Forward (normal switch operation) >> bit 5 = Monitor egress >> bit 4 = Monitor ingress >> bit 3:0 = CPU port >> */ >> >> >> Reading through the "Monitor Control" register description, there is a >> interesting description about the "ARPdest" setting... Could you try to >> set it to the CPU port and see if that helps? >> > > It's already set this way (sans bits 4&5) > REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0); > > I tried turning on bit 4 on port 0 (lan1.1). Now I can see what's > coming into that port, but it doesn't look right: > > Here's the ARP going out: > > 13:46:29.348449 00:1d:11:81:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x4000), length 46: > 0x0000: ffff ffff ffff 001d 1181 0000 4000 0000 > 0x0010: 0806 0001 0800 0604 0001 001d 1181 0000 > 0x0020: c0a8 0cbc 0000 0000 0000 c0a8 0c12 > > Here's the ARP reply coming back: > > 13:46:29.348907 00:1e:c9:2f:73:6c > 00:1d:11:81:00:00, ethertype Unknown (0x8004), length 64: > 0x0000: 001d 1181 0000 001e c92f 736c 8004 0000 > 0x0010: 0806 0001 0800 0604 0002 001e c92f 736c > 0x0020: c0a8 0c12 001d 1181 0000 c0a8 0cbc 0000 > 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 > > I understand the 0x4000 DSA tag going out, but what's the 0x8004? > Note: without the extra monitor bit (#4), I don't see these packets get back to my ethernet device. Maybe the tag says something of why? Any pointers on how I can test/debug the "VLAN" (internal routing) setup?
Gary Thomas wrote: > Gary Thomas wrote: >> Jesper Dangaard Brouer wrote: >>> On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote: >>>> Jesper Dangaard Brouer wrote: >>>>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote: >>>>>> Any ideas how I might troubleshoot why packets that come >>>>>> into lan1.1 (port 0) aren't being pushed to the CPU port? >>>>> The switch supports port monitoring, with seperate ingress and egress >>>>> mapping, thus you could place another PC on another port and direct >>>>> traffic towards that, and by tcpdump inspecting ingress and egress on >>>>> the different physical ports... Thats how I debugged it once... >>>> I'm a bit fuzzy on this - could you explain in a bit more detail? >>> You basically set the monitor destination port via REG_GLOBAL reg 0x1A >>> "Monitor Control". >>> >>> /* Register: Monitor Control (0x1A) >>> ------------------------- >>> bit 15:12= Ingress Monitor Dest >>> bit 11:8 = Egress Monitor Dest >>> bit 7:4 = ARP Dest >>> bit 3:0 = Reserved >>> */ >>> >>> Then you configure the port register 0x08 "port control2", that this >>> port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress. >>> >>> /* Register: Port Control 2 (0x8) >>> ------------------------ >>> bit 15 = IgnoreFSC: Force good FSC in frame >>> bit 14 = VTU_prio_override : VTU setting overrides prio >>> bit 13 = ATU_SA_prio_overrite: ATU SA setting overrides prio >>> bit 12 = ATU_DA_prio_overrite: ATU DA setting overrides prio >>> bit 11:10 = 802.1Q mode >>> [00] = <Disabled>: use VLANtable only >>> [01] = <Fallback>: fallback to VLANTable >>> [10] = <Check> : drop on miss (eq. not in VTU) >>> [11] = <Secure> : drop on miss and membership violation >>> bit 9 = Discard Tagged >>> bit 8 = Discard Untagged >>> bit 7 = MapDA: Map using DA hits >>> bit 6 = Default Forward (normal switch operation) >>> bit 5 = Monitor egress >>> bit 4 = Monitor ingress >>> bit 3:0 = CPU port >>> */ >>> >>> >>> Reading through the "Monitor Control" register description, there is a >>> interesting description about the "ARPdest" setting... Could you try to >>> set it to the CPU port and see if that helps? >>> >> It's already set this way (sans bits 4&5) >> REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0); >> >> I tried turning on bit 4 on port 0 (lan1.1). Now I can see what's >> coming into that port, but it doesn't look right: >> >> Here's the ARP going out: >> >> 13:46:29.348449 00:1d:11:81:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x4000), length 46: >> 0x0000: ffff ffff ffff 001d 1181 0000 4000 0000 >> 0x0010: 0806 0001 0800 0604 0001 001d 1181 0000 >> 0x0020: c0a8 0cbc 0000 0000 0000 c0a8 0c12 >> >> Here's the ARP reply coming back: >> >> 13:46:29.348907 00:1e:c9:2f:73:6c > 00:1d:11:81:00:00, ethertype Unknown (0x8004), length 64: >> 0x0000: 001d 1181 0000 001e c92f 736c 8004 0000 >> 0x0010: 0806 0001 0800 0604 0002 001e c92f 736c >> 0x0020: c0a8 0c12 001d 1181 0000 c0a8 0cbc 0000 >> 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 >> >> I understand the 0x4000 DSA tag going out, but what's the 0x8004? >> > > Note: without the extra monitor bit (#4), I don't see these packets > get back to my ethernet device. Maybe the tag says something of why? I found this tag in the 6131 manual - it basically says that it's a copied packet which was received on VID 0. Exactly as expected. > Any pointers on how I can test/debug the "VLAN" (internal routing) setup? Do you understand where (which register settings) cause packets which come in on lan1.1 (VID=0 I think, port 0) to be sent on to the CPU port (10) along with the TO_CPU tag? I've been through this document a dozen times and I still don't see where the mapping that direction happens...
On Mon, Mar 02, 2009 at 11:56:22AM +0100, Jesper Dangaard Brouer wrote: > > The main conclusion so far is that this write (net/dsa/mv88e6131.c): > > > > /* > > * MAC Forcing register: don't force link, speed, duplex > > * or flow control state to any particular values. > > */ > > REG_WRITE(addr, 0x01, 0x0003); > > This sort of enables auto-detection of speed. > > > isn't correct on ports that can either be CPU ports or external ports. > > For external ports I had to enabled the PPU to allow the external PHYs > to negotiate. The PPU should be re-enabled 10ms after the last MII access. > Also, on external PHYs ports 8 and 9, I write 0x0403 not 0x0003 (to > register 0x1, PCS Control Register). Which also enables inband > auto-negotiation, but I'm not sure this is necessary. Not sure whether it is. Gary? > > Forcing the link up on the CPU port helps somewhat, but things aren't > > 100% working yet. > > On the CPU port I force link-up and force speed+duplex setting. I only > got 100Mbit/s to the CPU port... I suppose the cpu port speed should be made into a platform data config option in case there's only a 100 Mb/s link on a gigabit capable switch? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 02, 2009 at 08:22:17AM -0700, Gary Thomas wrote: > >>> You should write 0x003E ... see attached patch > >> Ups, I see (from the thread) that you have already done/tried this... > > > > Yes, although I think it will need some work in the future > > (I've set it to 1000Mb connection, you said you used 100Mb, etc) > > > > Question: I'm testing this by trying a ping out of my box. > > Linux replies by sending an ARP packet out, and the destination > > replies with an ARP packet in. I can see from the ethtool stats > > that the reply packets get into lan1.1 (the physical port I'm > > using), but I don't see them get moved through the CPU port. > > My understanding is that this should work via the VLAN map? > > I checked that setup and it looks OK. > > > > Any ideas where this might be going wrong? > > I also just noticed that the ESA registers (Global 1,2,3) > aren't set at all. This is done by mv88e6xxx_set_addr_{in,}direct() in mv88e6xxx.c, via the ->set_addr() callback. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 02, 2009 at 11:05:29PM +0100, Jesper Dangaard Brouer wrote: > >>My understanding is that this should work via the VLAN map? > > I think that the "VLAN map/table" has gotten a wrong name as it does not > really determine the VLANs, it only says who can talk to whom. The switch > does support a real vlan setup, but its deactivated in Lennerts driver, as > I guess he wants Linux to handle the VLANs. (I use the real VLAN setup > extensively in my driver). I have some patches that make use of this (see the earlier h/w bridging patch I posted to netdev@ -- I've extended that to handle VLANs as well). Without those patches, each port will just have its own address database. > >>I checked that setup and it looks OK. > > I have also checked the different registers setting, and things looks > quite alright. Although I'm missing the register datasheets for the 6131 > chip, I found that I only have part 1 of 3 crap... > > I did find that the 6095 and 6097 does differ in the way DSA handling is > done, as the 6097 supports Ethertype DSA and 6095 don't. But the 6131 > driver looks like it does the right thing for the 6095. For the gigabit switches, there are more or less two groups of switches from a register programming point of view. Group 1: - models: 6045, 6045f, 6092, 6095, 6095f, 6121, 6122, 6131, 6152, 6155, 6182, 6185 - Support Header and DSA tagging. - MAC address programmed directly via global 1/2/3. - PPU handling generally needed. Group 2: - models: 6046, 6046f, 6085, 6096 (FE), 6097, 6097f, 6123, 6161, 6165 - Support Header, DSA and Ethertype DSA tagging. - MAC address programmed indirectly via global 1/2. - PPU handling generally not needed. - Extended stats access via bits [8:5] (And of course, various advanced queueing/filtering capabilities are only available in the higher end switches, but we don't use those capabilities for now.) So the 6095 is in the first group and the 6097 in the second. The 6131 driver can probably be very easily extended to handle all switches in the first group, and the 6123/6161/6165 driver can probably be easily extended to handle all switches in the second group. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Lennert Buytenhek wrote: > On Mon, Mar 02, 2009 at 11:56:22AM +0100, Jesper Dangaard Brouer wrote: > >>> The main conclusion so far is that this write (net/dsa/mv88e6131.c): >>> >>> /* >>> * MAC Forcing register: don't force link, speed, duplex >>> * or flow control state to any particular values. >>> */ >>> REG_WRITE(addr, 0x01, 0x0003); >> This sort of enables auto-detection of speed. >> >>> isn't correct on ports that can either be CPU ports or external ports. >> For external ports I had to enabled the PPU to allow the external PHYs >> to negotiate. > > The PPU should be re-enabled 10ms after the last MII access. > > >> Also, on external PHYs ports 8 and 9, I write 0x0403 not 0x0003 (to >> register 0x1, PCS Control Register). Which also enables inband >> auto-negotiation, but I'm not sure this is necessary. > > Not sure whether it is. Gary? > I'm not sure either. On my system, these ports are SERDES used to cascade switches. When we get that part working, we may learn if these bits are important. > >>> Forcing the link up on the CPU port helps somewhat, but things aren't >>> 100% working yet. >> On the CPU port I force link-up and force speed+duplex setting. I only >> got 100Mbit/s to the CPU port... > > I suppose the cpu port speed should be made into a platform data > config option in case there's only a 100 Mb/s link on a gigabit > capable switch? I agree.
diff --git a/net/dsa/mv88e6131.c b/net/dsa/mv88e6131.c index 374d46a..400473a 100644 --- a/net/dsa/mv88e6131.c +++ b/net/dsa/mv88e6131.c @@ -159,9 +159,13 @@ static int mv88e6131_setup_port(struct dsa_switch *ds, int p) /* * MAC Forcing register: don't force link, speed, duplex - * or flow control state to any particular values. + * or flow control state to any particular values. Unless + * this is the CPU port, then force 1Gb/s and link-up. */ - REG_WRITE(addr, 0x01, 0x0003); + if ((p == ds->cpu_port)) + REG_WRITE(addr, 0x01, 0x003E); + else + REG_WRITE(addr, 0x01, 0x0003); /* * Port Control: disable Core Tag, disable Drop-on-Lock,