So I did some experimenting with locking, but eventually found that this chunk:

@@ -2677,10 +2681,18 @@ static void rtl8169_tx_interrupt(struct net_device *dev,

    if (tp->dirty_tx != dirty_tx) {
        tp->dirty_tx = dirty_tx;
- -        smp_wmb();
- -        if (netif_queue_stopped(dev) &&
- -            (TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) {
- -            netif_wake_queue(dev);
+        smp_mb();
+        if (unlikely(netif_queue_stopped(dev))) {
+            netif_tx_lock(dev);
+                if (TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)
+                netif_wake_queue(dev);
+            if (dirty_tx != tp->cur_tx)
+                RTL_W8(TxPoll, NPQ);
+            netif_tx_unlock(dev);
+        } else if (dirty_tx != tp->cur_tx) {
+            netif_tx_lock(dev);
+            RTL_W8(TxPoll, NPQ);
+            netif_tx_unlock(dev);
        }
    }
}

from the patch in http://www.spinics.net/lists/netdev/msg33960.html
was sufficient to fix the stuck TX queue bug without the busy-wait. Actually just the else portion of the above chunk was sufficient in my testing, without
the barrier change or the if statement change.

David Gundersen pointed me to this potential fix days ago, but I didn't
consider it first since the change had (presumably intentionally) been dropped from
the set of diffs Francois pointed me to.  Given that I had reported the same
problem as David Gundersen (and Dirk, and other samba users...) I thought this
patch had been ruled out.  Apparently not.  Hopefully this can be dusted off
and made into a fairly high priority fix as it has been biting realtek users
since last year at least.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to