Bug 16188

Summary: download stalls/stops
Product: Drivers Reporter: Heinz Diehl (htd)
Component: NetworkAssignee: drivers_network (drivers_network)
Status: RESOLVED PATCH_ALREADY_AVAILABLE    
Severity: high CC: linville, rjw
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.35-rc3 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: output of lsusb -vv
my kernel .config
boot.msg

Description Heinz Diehl 2010-06-12 17:30:26 UTC 
Hi,
with 2.6.35-rc3, downloading a file (e.g. a bzipped Linux kernel from kernel.org) does quite often not initiate, or it stalls forever after some few megabytes.
I can easily reproduce it with both 2.6.35-rc3 and 2.6.35-rc2-git6, have just to try 1-3 times to download something. It's not related to a special website or IP, and it's not related to a special file either.

2.6.35-rc2 was fine, and so is the 2.6.34 stable branch.

The thing is, absolutely nothing is showing up in the logfiles or in dmesg, or any other logfile I'm aware of.

I've attached the boot.msg, .config and output of lsusb -vv, I'm somewhat puzzled what's the problem here, but it's definitely kernel related.

Please contact me if you need more information.

Regards,
Heinz.
Comment 1 Heinz Diehl 2010-06-12 17:31:18 UTC 
Created attachment 26743 [details]
output of lsusb -vv
Comment 2 Heinz Diehl 2010-06-12 17:32:04 UTC 
Created attachment 26744 [details]
my kernel .config
Comment 3 Heinz Diehl 2010-06-12 17:32:46 UTC 
Created attachment 26745 [details]
boot.msg
Comment 4 Heinz Diehl 2010-06-12 18:11:50 UTC 
Did a bunch of recompiles and reboots, and found out that this bug was introduced with 2.6.35-rc2-git6, -rc2-git5 was fine.
Comment 5 Heinz Diehl 2010-06-13 15:26:00 UTC 
This seems to be the fix, no problems after ca. 10 downloads with the patched 2.6.35-rc3. See also http://lkml.org/lkml/2010/6/13/59 :

--- dev.c.orig	2010-06-12 04:14:04.000000000 +0200
+++ dev.c	2010-06-13 16:56:33.000000000 +0200
@@ -2810,24 +2810,14 @@
 	if (!skb->skb_iif)
 		skb->skb_iif = skb->dev->ifindex;
 
-	/*
-	 * bonding note: skbs received on inactive slaves should only
-	 * be delivered to pkt handlers that are exact matches.  Also
-	 * the deliver_no_wcard flag will be set.  If packet handlers
-	 * are sensitive to duplicate packets these skbs will need to
-	 * be dropped at the handler.  The vlan accel path may have
-	 * already set the deliver_no_wcard flag.
-	 */
 	null_or_orig = NULL;
 	orig_dev = skb->dev;
 	master = ACCESS_ONCE(orig_dev->master);
-	if (skb->deliver_no_wcard)
-		null_or_orig = orig_dev;
-	else if (master) {
-		if (skb_bond_should_drop(skb, master)) {
-			skb->deliver_no_wcard = 1;
+
+        if (master) {
+              if (skb_bond_should_drop(skb, master))
 			null_or_orig = orig_dev; /* deliver only exact match */
-		} else
+		else
 			skb->dev = master;
 	}
Comment 6 Rafael J. Wysocki 2010-06-13 17:40:07 UTC 
Caused by:

commit 597a264b1a9c7e36d1728f677c66c5c1f7e3b837
Author: John Fastabend <john.r.fastabend@intel.com>
Date:   Thu Jun 3 09:30:11 2010 +0000

    net: deliver skbs on inactive slaves to exact matches

    Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

First-Bad-Commit : 597a264b1a9c7e36d1728f677c66c5c1f7e3b837
Comment 7 Andreas Schwab 2010-06-14 19:34:45 UTC 
Fixed by e897082fe7a5b591dc4dd5599ac39081a7c8e482 (net: fix deliver_no_wcard regression on loopback device) in net-2.6.