[PATCH] r8169: revert "add byte queue limit support".

[PATCH] r8169: revert "add byte queue limit support".

[Francois Romieu]

This reverts commit 036dafa28da1e2565a8529de2ae663c37b7a0060.

First it appears in bisection, then reverting it solves the usual
netdev watchdog problem for different people. I don't have a proper
fix yet so get rid of it.

Bisected-and-reported-by: Alex Villacís Lasso <a_villacis@palosanto.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: Hayes Wang <hayeswang@realtek.com>
---

 The original 036da... commit has been modified due to the newly introduced
 skb_tx_timestamp in rtl8169_start_xmit. The herein included patch qualifies
 for 3.4-stable as well.

 drivers/net/ethernet/realtek/r8169.c |   27 +++++----------------------
 1 file changed, 5 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index d7a04e0..eb81da4 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5380,7 +5380,6 @@ static void rtl8169_tx_clear(struct rtl8169_private *tp)
 {
 	rtl8169_tx_clear_range(tp, tp->dirty_tx, NUM_TX_DESC);
 	tp->cur_tx = tp->dirty_tx = 0;
-	netdev_reset_queue(tp->dev);
 }
 
 static void rtl_reset_work(struct rtl8169_private *tp)
@@ -5535,8 +5534,6 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
 
 	txd->opts2 = cpu_to_le32(opts[1]);
 
-	netdev_sent_queue(dev, skb->len);
-
 	skb_tx_timestamp(skb);
 
 	wmb();
@@ -5633,16 +5630,9 @@ static void rtl8169_pcierr_interrupt(struct net_device *dev)
 	rtl_schedule_task(tp, RTL_FLAG_TASK_RESET_PENDING);
 }
 
-struct rtl_txc {
-	int packets;
-	int bytes;
-};
-
 static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp)
 {
-	struct rtl8169_stats *tx_stats = &tp->tx_stats;
 	unsigned int dirty_tx, tx_left;
-	struct rtl_txc txc = { 0, 0 };
 
 	dirty_tx = tp->dirty_tx;
 	smp_rmb();
@@ -5661,24 +5651,17 @@ static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp)
 		rtl8169_unmap_tx_skb(&tp->pci_dev->dev, tx_skb,
 				     tp->TxDescArray + entry);
 		if (status & LastFrag) {
-			struct sk_buff *skb = tx_skb->skb;
-
-			txc.packets++;
-			txc.bytes += skb->len;
-			dev_kfree_skb(skb);
+			u64_stats_update_begin(&tp->tx_stats.syncp);
+			tp->tx_stats.packets++;
+			tp->tx_stats.bytes += tx_skb->skb->len;
+			u64_stats_update_end(&tp->tx_stats.syncp);
+			dev_kfree_skb(tx_skb->skb);
 			tx_skb->skb = NULL;
 		}
 		dirty_tx++;
 		tx_left--;
 	}
 
-	u64_stats_update_begin(&tx_stats->syncp);
-	tx_stats->packets += txc.packets;
-	tx_stats->bytes += txc.bytes;
-	u64_stats_update_end(&tx_stats->syncp);
-
-	netdev_completed_queue(dev, txc.packets, txc.bytes);
-
 	if (tp->dirty_tx != dirty_tx) {
 		tp->dirty_tx = dirty_tx;
 		/* Sync with rtl8169_start_xmit:
-- 
1.7.10.4

Re: [PATCH] r8169: revert "add byte queue limit support".

[David Miller]

From: Francois Romieu <romieu@fr.zoreil.com>
Date: Mon, 23 Jul 2012 22:55:55 +0200

> This reverts commit 036dafa28da1e2565a8529de2ae663c37b7a0060.
> 
> First it appears in bisection, then reverting it solves the usual
> netdev watchdog problem for different people. I don't have a proper
> fix yet so get rid of it.
> 
> Bisected-and-reported-by: Alex Villacís Lasso <a_villacis@palosanto.com>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Josh Boyer <jwboyer@redhat.com>
> Cc: Hayes Wang <hayeswang@realtek.com>
> ---
> 
>  The original 036da... commit has been modified due to the newly introduced
>  skb_tx_timestamp in rtl8169_start_xmit. The herein included patch qualifies
>  for 3.4-stable as well.

Applied to net-next and queued up for -stable, thanks.

Re: [PATCH] r8169: revert "add byte queue limit support".

[Eric Dumazet]

On Mon, 2012-07-23 at 22:55 +0200, Francois Romieu wrote:
> This reverts commit 036dafa28da1e2565a8529de2ae663c37b7a0060.
> 
> First it appears in bisection, then reverting it solves the usual
> netdev watchdog problem for different people. I don't have a proper
> fix yet so get rid of it.
> 
> Bisected-and-reported-by: Alex Villacís Lasso <a_villacis@palosanto.com>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Josh Boyer <jwboyer@redhat.com>
> Cc: Hayes Wang <hayeswang@realtek.com>
> ---

bisection is not always the right way to qualify a problem.

BQL in itself had some fixes coming _after_ commit 036dafa28da1e2565

Is there an easy way to reproduce the problem ?

Thanks

Re: [PATCH] r8169: revert "add byte queue limit support".

[Eric Dumazet]

On Tue, 2012-07-24 at 07:06 +0200, Eric Dumazet wrote:
> On Mon, 2012-07-23 at 22:55 +0200, Francois Romieu wrote:
> > This reverts commit 036dafa28da1e2565a8529de2ae663c37b7a0060.
> > 
> > First it appears in bisection, then reverting it solves the usual
> > netdev watchdog problem for different people. I don't have a proper
> > fix yet so get rid of it.
> > 
> > Bisected-and-reported-by: Alex Villacís Lasso <a_villacis@palosanto.com>
> > Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> > Cc: Josh Boyer <jwboyer@redhat.com>
> > Cc: Hayes Wang <hayeswang@realtek.com>
> > ---
> 
> bisection is not always the right way to qualify a problem.
> 
> BQL in itself had some fixes coming _after_ commit 036dafa28da1e2565
> 
> Is there an easy way to reproduce the problem ?
> 
> Thanks
> 

BQL fixes are :

commit 914bec1011a25f65cdc94988a6f974bfb9a3c10d
Author: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date:   Wed May 30 12:25:37 2012 +0000

    bql: Avoid possible inconsistent calculation.
    
    dql->num_queued could change while processing dql_completed().
    To provide consistent calculation, added an on stack variable.
    
    Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
    Cc: Tom Herbert <therbert@google.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Denys Fedoryshchenko <denys@visp.net.lb>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 25426b794efdc70dde7fd3134dc56fac3e7d562d
Author: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date:   Wed May 30 12:25:19 2012 +0000

    bql: Avoid unneeded limit decrement.
    
    When below pattern is observed,
    
                                                   TIME
           dql_queued()         dql_completed()     |
          a) initial state                          |
                                                    |
          b) X bytes queued                         V
    
          c) Y bytes queued
                               d) X bytes completed
          e) Z bytes queued
                               f) Y bytes completed
    
    a) dql->limit has already some value and there is no in-flight
packet.
    b) X bytes queued.
    c) Y bytes queued and excess limit.
    d) X bytes completed and dql->prev_ovlimit is set and also
       dql->prev_num_queued is set Y.
    e) Z bytes queued.
    f) Y bytes completed. inprogress and prev_inprogress are true.
    
    At f), according to the comment, all_prev_completed becomes
    true and limit should be increased. But POSDIFF() ignores
    (completed == dql->prev_num_queued) case, so limit is decreased.
    
    Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
    Cc: Tom Herbert <therbert@google.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Denys Fedoryshchenko <denys@visp.net.lb>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 0cfd32b736ae0c36b42697584811042726c07cba
Author: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date:   Wed May 30 12:24:39 2012 +0000

    bql: Fix POSDIFF() to integer overflow aware.
    
    POSDIFF() fails to take into account integer overflow case.
    
    Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
    Cc: Tom Herbert <therbert@google.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Denys Fedoryshchenko <denys@visp.net.lb>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Re: [PATCH] r8169: revert "add byte queue limit support".

[Francois Romieu]

Eric Dumazet <eric.dumazet@gmail.com> :
> On Mon, 2012-07-23 at 22:55 +0200, Francois Romieu wrote:
> > This reverts commit 036dafa28da1e2565a8529de2ae663c37b7a0060.
[...]
> bisection is not always the right way to qualify a problem.

I know. At some point I switch from "I could search more" to "users situation
will improve in a definite timeframe".

> BQL in itself had some fixes coming _after_ commit 036dafa28da1e2565

Thanks.

They are in stable as of 3.4.5:

commit 4f4bdaeb40df95499c1ee7ea3fbca9d76174a59e
Author:     Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
AuthorDate: Wed May 30 12:25:37 2012 +0000
Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CommitDate: Mon Jul 16 09:03:43 2012 -0700

    bql: Avoid possible inconsistent calculation.
    
    [ Upstream commit 914bec1011a25f65cdc94988a6f974bfb9a3c10d ]
[...]
commit 1414a53d956340ca8b1b27e05ab94ba63e82ed97
Author:     Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
AuthorDate: Wed May 30 12:25:19 2012 +0000
Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CommitDate: Mon Jul 16 09:03:43 2012 -0700

    bql: Avoid unneeded limit decrement.

I have obviously not directed users at them and I do not see any
of the victims using a non -stable / -vendor or recent enough
kernel to test this patch since the issue has been reported.

They are both worth testing.

> Is there an easy way to reproduce the problem ?

None here :o(

-- 
Ueimor

Re: [PATCH] r8169: revert "add byte queue limit support".

[Josh Boyer]

On Tue, Jul 24, 2012 at 07:38:11AM +0200, Francois Romieu wrote:
> Eric Dumazet <eric.dumazet@gmail.com> :
> > On Mon, 2012-07-23 at 22:55 +0200, Francois Romieu wrote:
> > > This reverts commit 036dafa28da1e2565a8529de2ae663c37b7a0060.
> [...]
> > bisection is not always the right way to qualify a problem.
> 
> I know. At some point I switch from "I could search more" to "users situation
> will improve in a definite timeframe".
> 
> > BQL in itself had some fixes coming _after_ commit 036dafa28da1e2565
> 
> Thanks.
> 
> They are in stable as of 3.4.5:
> 
> commit 4f4bdaeb40df95499c1ee7ea3fbca9d76174a59e
> Author:     Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
> AuthorDate: Wed May 30 12:25:37 2012 +0000
> Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> CommitDate: Mon Jul 16 09:03:43 2012 -0700
> 
>     bql: Avoid possible inconsistent calculation.
>     
>     [ Upstream commit 914bec1011a25f65cdc94988a6f974bfb9a3c10d ]
> [...]
> commit 1414a53d956340ca8b1b27e05ab94ba63e82ed97
> Author:     Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
> AuthorDate: Wed May 30 12:25:19 2012 +0000
> Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> CommitDate: Mon Jul 16 09:03:43 2012 -0700
> 
>     bql: Avoid unneeded limit decrement.
> 
> I have obviously not directed users at them and I do not see any
> of the victims using a non -stable / -vendor or recent enough
> kernel to test this patch since the issue has been reported.
> 
> They are both worth testing.

Fedora has 3.4.5 in the F16 updates-testing repo.  F17 is already on
3.4.6 in stable updates.  Users should be able to use those kernels for
testing.  F16 will be getting 3.4.6 submitted this morning for
updates-testing.

josh

Re: [PATCH] r8169: revert "add byte queue limit support".

[Stefan Lippers-Hollmann]

Hi

On Tuesday 24 July 2012, Francois Romieu wrote:
> Eric Dumazet <eric.dumazet@gmail.com> :
> > On Mon, 2012-07-23 at 22:55 +0200, Francois Romieu wrote:
> > > This reverts commit 036dafa28da1e2565a8529de2ae663c37b7a0060.
> [...]
> > bisection is not always the right way to qualify a problem.
> 
> I know. At some point I switch from "I could search more" to "users situation
> will improve in a definite timeframe".
> 
> > BQL in itself had some fixes coming _after_ commit 036dafa28da1e2565
> 
> Thanks.
> 
> They are in stable as of 3.4.5:
[…]
> I have obviously not directed users at them and I do not see any
> of the victims using a non -stable / -vendor or recent enough
> kernel to test this patch since the issue has been reported.
> 
> They are both worth testing.
[…]

3.4.x up to and including 3.4.4 exposed the problem on these cards[1]:

r8169 0000:04:00.0: eth0: RTL8168d/8111d at 0xffffc90000c72000, 00:24:1d:72:7c:75, XID 081000c0 IRQ 44
r8169 0000:05:00.0: eth1: RTL8168d/8111d at 0xffffc90000c70000, 00:24:1d:72:7c:77, XID 081000c0 IRQ 45

while it is stable with "add byte queue limit support" reverted; 3.4.5+
was only tested with 036dafa28da1e2565a8529de2ae663c37b7a0060 reverted.

Now testing plain 3.5.0, which still includes it, has been reliable for
almost 3 days - while the issue usually triggered within one hour (3 
hours at most) in 3.4.[0-4]. It might be a little too early to give a
definitive answer, but so far r8169/ 3.5.0 looks positive.

Regards
	Stefan Lippers-Hollmann

[1]	Message-Id: <201206290131.49150.s.L-H@gmx.de>
	http://lkml.kernel.org/r/<201206290131.49150.s.L-H@gmx.de>

Re: [PATCH] r8169: revert "add byte queue limit support".

[Eric Dumazet]

On Fri, 2012-07-27 at 05:36 +0200, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On Tuesday 24 July 2012, Francois Romieu wrote:
> > Eric Dumazet <eric.dumazet@gmail.com> :
> > > On Mon, 2012-07-23 at 22:55 +0200, Francois Romieu wrote:
> > > > This reverts commit 036dafa28da1e2565a8529de2ae663c37b7a0060.
> > [...]
> > > bisection is not always the right way to qualify a problem.
> > 
> > I know. At some point I switch from "I could search more" to "users situation
> > will improve in a definite timeframe".
> > 
> > > BQL in itself had some fixes coming _after_ commit 036dafa28da1e2565
> > 
> > Thanks.
> > 
> > They are in stable as of 3.4.5:
> […]
> > I have obviously not directed users at them and I do not see any
> > of the victims using a non -stable / -vendor or recent enough
> > kernel to test this patch since the issue has been reported.
> > 
> > They are both worth testing.
> […]
> 
> 3.4.x up to and including 3.4.4 exposed the problem on these cards[1]:
> 
> r8169 0000:04:00.0: eth0: RTL8168d/8111d at 0xffffc90000c72000, 00:24:1d:72:7c:75, XID 081000c0 IRQ 44
> r8169 0000:05:00.0: eth1: RTL8168d/8111d at 0xffffc90000c70000, 00:24:1d:72:7c:77, XID 081000c0 IRQ 45
> 
> while it is stable with "add byte queue limit support" reverted; 3.4.5+
> was only tested with 036dafa28da1e2565a8529de2ae663c37b7a0060 reverted.
> 
> Now testing plain 3.5.0, which still includes it, has been reliable for
> almost 3 days - while the issue usually triggered within one hour (3 
> hours at most) in 3.4.[0-4]. It might be a little too early to give a
> definitive answer, but so far r8169/ 3.5.0 looks positive.
> 
> Regards
> 	Stefan Lippers-Hollmann
> 
> [1]	Message-Id: <201206290131.49150.s.L-H@gmx.de>
> 	http://lkml.kernel.org/r/<201206290131.49150.s.L-H@gmx.de>

Thats real good news, thanks !