[patch] 2.6.1-bk1-netdev4 - latent bug

[patch] 2.6.1-bk1-netdev4 - latent bug

[Francois Romieu]

Hi,

(disclaimer: I have not been especially brilliant these last days, so
handle with care)

  the following patch against -netdev4 should fix an error which appears in
every r8169 driver (-vanilla, -mm, -netdev, -my). The patch will not apply
against plain 2.6.x due to endianness conflict. I will regenerate a serie
for 2.6.1-bk1 in a few minutes.

It has not been tested so far but it could be a decent candidate for
lock-up under stress.

Please review rtl8169_tx_interrupt/rtl8169_start_xmit and/or test if you can.



- possible tx descriptor index overflow (assume tp->dirty_tx = NUM_TX_DESC/2,
  tp->cur_tx = NUM_TX_DESC - 1 for example);
- the status of an inadequate descriptor is checked.

When tx_dirty == 1, one should not necessarily notice a difference.


 drivers/net/r8169.c |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

diff -puN drivers/net/r8169.c~r8169-tx-index-overflow drivers/net/r8169.c
--- linux-2.6.1-bk1-netdev4/drivers/net/r8169.c~r8169-tx-index-overflow	2004-01-14 23:16:58.000000000 +0100
+++ linux-2.6.1-bk1-netdev4-fr/drivers/net/r8169.c	2004-01-14 23:16:58.000000000 +0100
@@ -1341,8 +1341,7 @@ static void
 rtl8169_tx_interrupt(struct net_device *dev, struct rtl8169_private *tp,
 		     void *ioaddr)
 {
-	unsigned long dirty_tx, tx_left = 0;
-	int entry = tp->cur_tx % NUM_TX_DESC;
+	unsigned long dirty_tx, tx_left;
 
 	assert(dev != NULL);
 	assert(tp != NULL);
@@ -1352,8 +1351,9 @@ rtl8169_tx_interrupt(struct net_device *
 	tx_left = tp->cur_tx - dirty_tx;
 
 	while (tx_left > 0) {
-		if (!(le32_to_cpu(tp->TxDescArray[entry].status) & OWNbit)) {
-			int cur = dirty_tx % NUM_TX_DESC;
+		int cur = dirty_tx % NUM_TX_DESC;
+
+		if (!(le32_to_cpu(tp->TxDescArray[cur].status) & OWNbit)) {
 			struct sk_buff *skb = tp->Tx_skbuff[cur];
 
 			/* FIXME: is it really accurate for TxErr ? */
@@ -1365,7 +1365,6 @@ rtl8169_tx_interrupt(struct net_device *
 			dev_kfree_skb_irq(skb);
 			dirty_tx++;
 			tx_left--;
-			entry++;
 		}
 	}
 

_

Re: [patch] 2.6.1-bk1-netdev4 - latent bug

[Francois Romieu]

Francois Romieu <romieu@fr.zoreil.com> :
[bug expected in common revisions of r8169 driver ?]
> against plain 2.6.x due to endianness conflict. I will regenerate a serie
> for 2.6.1-bk1 in a few minutes.

Serie available at:
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1-b

Tarball:
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1-b/r8169-blob.tar.bz2

I will welcome feedback related to the behavior of the driver once the
following serie is applied on top of 2.6.1-bk1 (may apply to 2.6.1 as well):
r8169-dma-api-tx.patch
r8169-dma-api-rx-buffers.patch
r8169-dma-api-rx-buffers-ahum.patch
r8169-dma-api-rx-buffers-argl.patch
r8169-rx-fill-typo.patch
r8169-start-xmit-fixes.patch
r8169-dma-api-tx-buffers.patch
r8169-tx-index-overflow.patch

No intermediate tests needed.

--
Ueimor

Re: [patch] 2.6.1-bk1-netdev4 - latent bug

[DaMouse Networks]

Organization: DaMouse Networks
X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

SMP-Enabled Kernel, 
i was pinging my router (Win2k Server) which seems to be pretty good at withstanding ping -f :) and I went downstairs and checked it was still alive after I lost contact, 
hey netdev peeps and peepesses, my computer is still alive and glowing blue :P

-DaMouse

On Thu, 15 Jan 2004 09:07:31 +0100
Francois Romieu <romieu@fr.zoreil.com> wrote:

> DaMouse Networks <damouse@ntlworld.com> :
> [...]
> > --- 192.168.0.1 ping statistics ---
> > 29918 packets transmitted, 16354 received, 45% packet loss, time 290162ms
> > rtt min/avg/max/mdev = 0.379/0.398/10.352/0.181 ms, ipg/ewma 9.698/0.389 ms
> 
> Btw, you can/may lower the packet size during ping (see -s option).
> 
> [...]
> > Then  I try again  and I get this:
> > 
> > PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
> > >From 192.168.0.94 icmp_seq=9 Destination Host Unreachable
> 
> Ok, I'll dig that. It does not seem _too_ bad.
> - is your modem able to stand a ping -f without loss ?
> - were you running an smp-enabled kernel ?
> - can you Cc: netdev so people know that your computer survived ?
> 
> Thanks for the quick feedback.
> 
> --
> Ueimor