r8169: workaround against ignored TxPoll writes (8168)
authorFrancois Romieu <romieu@fr.zoreil.com>
Sun, 26 Aug 2007 18:08:19 +0000 (20:08 +0200)
committerFrancois Romieu <romieu@electric-eye.fr.zoreil.com>
Wed, 19 Sep 2007 19:52:18 +0000 (21:52 +0200)
The 8168 ignores the requests to fetch the Tx descriptors when
the relevant TxPoll bit is already set. It easily kills the
performances of the 8168. David Gundersen has noticed that it
is enough to wait for the completion of the DMA transfer (NPQ
bit is cleared) before writing the TxPoll register again.

The extra IO traffic added by the proposed workaround could be
minimalized but it is not a high-priority task.

Fix for:
http://bugzilla.kernel.org/show_bug.cgi?id=7924
http://bugzilla.kernel.org/show_bug.cgi?id=8688
(http://bugzilla.kernel.org/show_bug.cgi?id=7555 ?)

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: David Gundersen <gundy@iinet.net.au>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
drivers/net/r8169.c

index d9bb51bb4b9db17d2264b02713edfa4e5640ea56..c921ec32c232cb265323f9075a2daf27275e188b 100644 (file)
@@ -2570,6 +2570,15 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
                    (TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) {
                        netif_wake_queue(dev);
                }
+               /*
+                * 8168 hack: TxPoll requests are lost when the Tx packets are
+                * too close. Let's kick an extra TxPoll request when a burst
+                * of start_xmit activity is detected (if it is not detected,
+                * it is slow enough). -- FR
+                */
+               smp_rmb();
+               if (tp->cur_tx != dirty_tx)
+                       RTL_W8(TxPoll, NPQ);
        }
 }