Re: r8169 driver cause ssh failure

On 12.05.2013 05:13, S L wrote:

commit e5195c1f31f399289347e043d6abf3ffa80f0005 cause ssh KEXINIT failure.
the hardware is ASROCK B75 PRO3. dmesg show

[    1.332961] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.333262] r8169 0000:03:00.0: irq 42 for MSI/MSI-X
[    1.333414] r8169 0000:03:00.0 eth0: RTL8168evl/8111evl at
0xffffc90000024000, 11:11:11:11:11:11, XID 0c900800 IRQ 42
[    1.333534] r8169 0000:03:00.0 eth0: jumbo features [frames: 9200 bytes,
tx checksumming: ko]

lspci -vn show

03:00.0 0200: 10ec:8168 (rev 06)
        Subsystem: 1849:8168

That does not contain much detail information. Also its not too helpful to send
such reports only to one person. I did not see ssh problems on my tests but that
could be a different configuration/environment.

-Stefan

Stefan Bader [off-list ref] :
[...]

That does not contain much detail information.

Offload parameters (ethtool -k) and network capture file would help a lot.

-- 
Ueimor

On Mon, 13 May 2013 08:33:32 +0200, Francois Romieu wrote:

Stefan Bader [off-list ref] :
[...]

quoted

That does not contain much detail information.

Offload parameters (ethtool -k) and network capture file would help a lot.

Don't have a packet capture, but I also noticed that this commit caused
failures; symptom for me was broken squid traffic to websites using CDNs
(arstechnica, twitter) and/or DNS, probably related to mixed IPv4/v6
traffic. See my followup to last week's 3.8.13-stable announcement, which
was apparently not dramatic enough to warrant attention.

I later found out that this regression is related to tx offloading;
enabling rx & gso offloading still works. Reverting the patch restores tx
offloading as well.

-h

Holger Hoffstaette [off-list ref] :
[...]

Don't have a packet capture, but I also noticed that this commit caused
failures; symptom for me was broken squid traffic to websites using CDNs
(arstechnica, twitter) and/or DNS, probably related to mixed IPv4/v6
traffic. See my followup to last week's 3.8.13-stable announcement, which
was apparently not dramatic enough to warrant attention.

It was not Cced and it did not appear as a reply to the stable-submitted
r8169 patch.

I later found out that this regression is related to tx offloading;
enabling rx & gso offloading still works. Reverting the patch restores tx
offloading as well.

Could you check if the patch below helps ?

It has not crashed yet but I still lack a test case to claim it makes
a difference.

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 79c520b..a05596c 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c

@@ -5856,7 +5856,15 @@ err_out:
 	return -EIO;
 }
 
-static inline void rtl8169_tso_csum(struct rtl8169_private *tp,
+static bool rtl_skb_pad(struct sk_buff *skb)
+{
+	if (skb_padto(skb, ETH_ZLEN))
+		return false;
+	skb_put(skb, ETH_ZLEN - skb->len);
+	return true;
+}
+
+static inline bool rtl8169_tso_csum(struct rtl8169_private *tp,
 				    struct sk_buff *skb, u32 *opts)
 {
 	const struct rtl_tx_desc_info *info = tx_desc_info + tp->txd_version;

@@ -5869,13 +5877,24 @@ static inline void rtl8169_tso_csum(struct rtl8169_private *tp,
 	} else if (skb->ip_summed == CHECKSUM_PARTIAL) {
 		const struct iphdr *ip = ip_hdr(skb);
 
+		if (unlikely(skb->len < ETH_ZLEN &&
+		    (tp->mac_version == RTL_GIGA_MAC_VER_34))) {
+			skb_checksum_help(skb);
+			return rtl_skb_pad(skb);
+		}
+
 		if (ip->protocol == IPPROTO_TCP)
 			opts[offset] |= info->checksum.tcp;
 		else if (ip->protocol == IPPROTO_UDP)
 			opts[offset] |= info->checksum.udp;
 		else
 			WARN_ON_ONCE(1);
+	} else {
+		if (unlikely(skb->len < ETH_ZLEN &&
+		    (tp->mac_version == RTL_GIGA_MAC_VER_34)))
+			return rtl_skb_pad(skb);
 	}
+	return true;
 }
 
 static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,

@@ -5896,17 +5915,15 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
 		goto err_stop_0;
 	}
 
-	/* 8168evl does not automatically pad to minimum length. */
-	if (unlikely(tp->mac_version == RTL_GIGA_MAC_VER_34 &&
-		     skb->len < ETH_ZLEN)) {
-		if (skb_padto(skb, ETH_ZLEN))
-			goto err_update_stats;
-		skb_put(skb, ETH_ZLEN - skb->len);
-	}
-
 	if (unlikely(le32_to_cpu(txd->opts1) & DescOwn))
 		goto err_stop_0;
 
+	opts[1] = cpu_to_le32(rtl8169_tx_vlan_tag(skb));
+	opts[0] = DescOwn;
+
+	if (!rtl8169_tso_csum(tp, skb, opts))
+		goto err_update_stats;
+
 	len = skb_headlen(skb);
 	mapping = dma_map_single(d, skb->data, len, DMA_TO_DEVICE);
 	if (unlikely(dma_mapping_error(d, mapping))) {

@@ -5918,11 +5935,6 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
 	tp->tx_skb[entry].len = len;
 	txd->addr = cpu_to_le64(mapping);
 
-	opts[1] = cpu_to_le32(rtl8169_tx_vlan_tag(skb));
-	opts[0] = DescOwn;
-
-	rtl8169_tso_csum(tp, skb, opts);
-
 	frags = rtl8169_xmit_frags(tp, skb, opts);
 	if (frags < 0)
 		goto err_dma_1;

On 15.05.2013 00:54, Francois Romieu wrote:

Could you check if the patch below helps ?

Seems to work fine! I have turned tx offloading back on and everything
works again, just like before the regression.

Thanks!

-h