| Message ID | CAL4WiiphpyizVaNkvOdJp1+UK53TkGw9RXnC-vzH7fTNpBAAEA@mail.gmail.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
11.10.2011 15:25, Eric Dumazet wrote: >> So, is that a hardware limitation? > > Its a driver bug > > This comes from fact that sizeof(struct rfd) = 16 > > and VLAN_ETH_FRAME_LEN is 1518 > > driver mixes VLAN_ETH_FRAME_LEN and 1500+4+sizeof(struct rfd) (1520, not 1518) > > It therefore misses 2 bytes for large frames (VLAN tagged) > > Fix is to remove VLAN_ETH_FRAME_LEN references for good... > > diff --git a/drivers/net/e100.c b/drivers/net/e100.c > index c1352c6..3287d31 100644 Hmm. This does not _exactly_ work. I applied it on top of 2.6.32, patch applied but with some fuzz - I checked manually and it appears to be ok. Now, with this patch applied, I see on the e100 side: 00:1f:c6:ef:e5:1b > 00:90:27:30:6d:1c, ethertype 802.1Q (0x8100), length 1504: vlan 6, p 0, ethertype IPv4, truncated-ip - 1 bytes missing! (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1487) 10.48.6.1 > 10.48.6.2: ICMP echo request, id 27613, seq 6, length 1467 when pinging it with -s 1459 (1487 total size). I added extra +40 for RFD_BUF_LEN define and recompiled (this resulted in RFD_BUF_LEN=1560, - I've added a printk just to be sure). Now I see the same effect as before the patch: maximum packet size that goes and can be seen on the e100 side is 1468(1496) (ping), which results in this on e100 side: 15:54:44.830941 00:1f:c6:ef:e5:1b > 00:90:27:30:6d:1c, ethertype 802.1Q (0x8100), length 1514: vlan 6, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1496) 10.48.6.1 > 10.48.6.2: ICMP echo request, id 28735, seq 4, length 1476 15:54:44.831025 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype 802.1Q (0x8100), length 1514: vlan 6, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 12010, offset 0, flags [none], proto ICMP (1), length 1496) 10.48.6.2 > 10.48.6.1: ICMP echo reply, id 28735, seq 4, length 1476 (and it works). With -s 1469, no ICMP packets can be seen on e100 side. So it still may be the hardware... :) Thank you! /mjt -- 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
Le mardi 11 octobre 2011 à 15:59 +0400, Michael Tokarev a écrit : > Hmm. This does not _exactly_ work. > > I applied it on top of 2.6.32, patch applied but with some fuzz - I checked > manually and it appears to be ok. > > Now, with this patch applied, I see on the e100 side: > > 00:1f:c6:ef:e5:1b > 00:90:27:30:6d:1c, ethertype 802.1Q (0x8100), length 1504: vlan 6, p 0, ethertype IPv4, truncated-ip - 1 bytes missing! (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1487) > 10.48.6.1 > 10.48.6.2: ICMP echo request, id 27613, seq 6, length 1467 > > when pinging it with -s 1459 (1487 total size). > > I added extra +40 for RFD_BUF_LEN define and recompiled > (this resulted in RFD_BUF_LEN=1560, - I've added a printk > just to be sure). > > Now I see the same effect as before the patch: maximum > packet size that goes and can be seen on the e100 side > is 1468(1496) (ping), which results in this on e100 side: > > 15:54:44.830941 00:1f:c6:ef:e5:1b > 00:90:27:30:6d:1c, ethertype 802.1Q (0x8100), length 1514: vlan 6, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1496) > 10.48.6.1 > 10.48.6.2: ICMP echo request, id 28735, seq 4, length 1476 > 15:54:44.831025 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype 802.1Q (0x8100), length 1514: vlan 6, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 12010, offset 0, flags [none], proto ICMP (1), length 1496) > 10.48.6.2 > 10.48.6.1: ICMP echo reply, id 28735, seq 4, length 1476 > > (and it works). With -s 1469, no ICMP packets can be seen > on e100 side. > > So it still may be the hardware... :) Yes, my patch was not needed, I was not sure sizeof(struct rfd) was included or not in the rfd.size setting (apparently its not needed) Any counters increase in "ethtool -S eth0" ? -- 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
11.10.2011 16:04, Eric Dumazet wrote: > Le mardi 11 octobre 2011 à 15:59 +0400, Michael Tokarev a écrit : [] >> (and it works). With -s 1469, no ICMP packets can be seen >> on e100 side. >> >> So it still may be the hardware... :) > > Yes, my patch was not needed, I was not sure sizeof(struct rfd) was > included or not in the rfd.size setting (apparently its not needed) Ok, good to know! > Any counters increase in "ethtool -S eth0" ? None at all. Number of interrupts gets increased by 2 about every 2 seconds, even when the other side is doing ping -f, or not pinging at all. So it looks like the card merely ignores these packets. So little result for so much efforts... :( But it is not really that bad I think - it is an obsolete hardware. Thank you for all the help! /mjt -- 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 Tue, Oct 11, 2011 at 04:56:23PM +0400, Michael Tokarev wrote: > So it looks like the card merely ignores these packets. > > So little result for so much efforts... :( > > But it is not really that bad I think - it is an obsolete hardware. The knowledge and code for this is actually around line 1142 of e100.c: if (nic->mac >= mac_82558_D101_A4) { config->fc_disable = 0x1; /* 1=Tx fc off, 0=Tx fc on */ config->mwi_enable = 0x1; /* 1=enable, 0=disable */ config->standard_tcb = 0x0; /* 1=standard, 0=extended */ config->rx_long_ok = 0x1; /* 1=VLANs ok, 0=standard */ where rx_long_ok is the configuration bit to enable frame reception for >1514 byte frames. I guess your card is < mac_82558_D101_A4... (cf. "Intel 8255x 10/100 Mbps Ethernet Controller Family Open Source Software Developer Manual" page 78/86 - "Long Receive OK. This bit is reserved on the 82557 and should be set to 0. When this bit is set on the 82558 or 82559, the device considers received frames that have a data field longer than 1500 bytes as good frames.") -David -- 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 Tue, 11 Oct 2011 08:29:18 -0700 David Lamparter <equinox@diac24.net> wrote: > On Tue, Oct 11, 2011 at 04:56:23PM +0400, Michael Tokarev wrote: > > So it looks like the card merely ignores these packets. > > > > So little result for so much efforts... :( > > > > But it is not really that bad I think - it is an obsolete hardware. > > The knowledge and code for this is actually around line 1142 of e100.c: > if (nic->mac >= mac_82558_D101_A4) { > config->fc_disable = 0x1; /* 1=Tx fc off, 0=Tx fc on */ > config->mwi_enable = 0x1; /* 1=enable, 0=disable */ > config->standard_tcb = 0x0; /* 1=standard, 0=extended */ > config->rx_long_ok = 0x1; /* 1=VLANs ok, 0=standard */ > > where rx_long_ok is the configuration bit to enable frame reception > for >1514 byte frames. I guess your card is < mac_82558_D101_A4... > > (cf. "Intel 8255x 10/100 Mbps Ethernet Controller Family Open Source > Software Developer Manual" page 78/86 - "Long Receive OK. This bit is > reserved on the 82557 and should be set to 0. When this bit is set on > the 82558 or 82559, the device considers received frames that have > a data field longer than 1500 bytes as good frames.") David, thank you for posting that, while you were typing I was researching the same thing, so FWIW, I concur with your conclusion. ouch, OP your hardware is really really old: > 00:12.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 02) > Subsystem: Intel Corporation EtherExpress PRO/100B (TX) rev 2 is D100_C, which is 82557. the hardware is NOT capable of long receives (i.e. vlan packets). If it was then they should generally fit in the receive buffer and be handled and not discarded.
On 12.10.2011 03:38, Jesse Brandeburg wrote: [..] >> The knowledge and code for this is actually around line 1142 of e100.c: >> if (nic->mac >= mac_82558_D101_A4) { >> config->fc_disable = 0x1; /* 1=Tx fc off, 0=Tx fc on */ >> config->mwi_enable = 0x1; /* 1=enable, 0=disable */ >> config->standard_tcb = 0x0; /* 1=standard, 0=extended */ >> config->rx_long_ok = 0x1; /* 1=VLANs ok, 0=standard */ >> >> where rx_long_ok is the configuration bit to enable frame reception >> for >1514 byte frames. I guess your card is < mac_82558_D101_A4... >> >> (cf. "Intel 8255x 10/100 Mbps Ethernet Controller Family Open Source >> Software Developer Manual" page 78/86 - "Long Receive OK. This bit is >> reserved on the 82557 and should be set to 0. When this bit is set on >> the 82558 or 82559, the device considers received frames that have >> a data field longer than 1500 bytes as good frames.") > > David, thank you for posting that, while you were typing I was > researching the same thing, so FWIW, I concur with your conclusion. > > ouch, OP your hardware is really really old: >> 00:12.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 02) >> Subsystem: Intel Corporation EtherExpress PRO/100B (TX) > > rev 2 is D100_C, which is 82557. > > the hardware is NOT capable of long receives (i.e. vlan packets). > If it was then they should generally fit in the receive buffer and be > handled and not discarded. Can this knowlege be added to the driver somehow, so that others will not hit the same trap as I did? :) _If_ there's any value in that (I guess there aren't many users with that hardware left), and if that's easy to do ofcourse... ;) Thanks! /mjt -- 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
diff --git a/drivers/net/e100.c b/drivers/net/e100.c index c1352c6..3287d31 100644 --- a/drivers/net/e100.c +++ b/drivers/net/e100.c @@ -435,6 +435,7 @@ struct rfd { __le16 actual_size; __le16 size; }; +#define RFD_BUF_LEN (sizeof(struct rfd) + ETH_DATA_LEN + VLAN_HLEN) struct rx { struct rx *next, *prev; @@ -1075,7 +1076,7 @@ static void e100_get_defaults(struct nic *nic) /* Template for a freshly allocated RFD */ nic->blank_rfd.command = 0; nic->blank_rfd.rbd = cpu_to_le32(0xFFFFFFFF); - nic->blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN); + nic->blank_rfd.size = cpu_to_le16(RFD_BUF_LEN); /* MII setup */ nic->mii.phy_id_mask = 0x1F; @@ -1881,7 +1882,6 @@ static inline void e100_start_receiver(struct nic *nic, struct rx *rx) } } -#define RFD_BUF_LEN (sizeof(struct rfd) + VLAN_ETH_FRAME_LEN) static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx) {
> So, is that a hardware limitation? Its a driver bug This comes from fact that sizeof(struct rfd) = 16 and VLAN_ETH_FRAME_LEN is 1518 driver mixes VLAN_ETH_FRAME_LEN and 1500+4+sizeof(struct rfd) (1520, not 1518) It therefore misses 2 bytes for large frames (VLAN tagged) Fix is to remove VLAN_ETH_FRAME_LEN references for good... if (!(rx->skb = netdev_alloc_skb_ip_align(nic->netdev, RFD_BUF_LEN))) @@ -2058,7 +2058,7 @@ static void e100_rx_clean(struct nic *nic, unsigned int *work_done, pci_dma_sync_single_for_device(nic->pdev, old_before_last_rx->dma_addr, sizeof(struct rfd), PCI_DMA_BIDIRECTIONAL); - old_before_last_rfd->size = cpu_to_le16(VLAN_ETH_FRAME_LEN); + old_before_last_rfd->size = cpu_to_le16(RFD_BUF_LEN); pci_dma_sync_single_for_device(nic->pdev, old_before_last_rx->dma_addr, sizeof(struct rfd), PCI_DMA_BIDIRECTIONAL);