Re: [PATCH] Re: rtl8169 problem and 2.4.23

Re: [PATCH] Re: rtl8169 problem and 2.4.23

[Francois Romieu]

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

Jeff,

  can you push the attached patch directly to both 2.6.x and 2.4.x ?
It will exhibit an offset of 3 lines against 2.4.x but it works the same
on 2.4.x and on 2.6.x. The fix already exists in -mm/-netdev serie.

Daniel Egger <degger@fhm.edu> confirmed I did not manage to add a giant
typo in a 4 lines patch. When hit, this bug is more or less a killer.

Daniel, I have no clear idea for the performance issues. Actually I am more
concerned with the stability side of this driver, especially in the new,
shamelessly hacked, branch of the driver. I'll probably regenerate a set
of patches and spam^W reach the testers to have a new data point.

--
Ueimor

[-- Attachment #2: r8169-tx-desc-overflow.patch --]
[-- Type: text/plain, Size: 1210 bytes --]

Assume tp->dirty_tx = NUM_TX_DESC/2, tp->cur_tx = NUM_TX_DESC - 1,
watch "entry" go beyond NUM_TX_DESC. This bug was copied from the 
(2.6.x only) sis190 driver where it is now fixed.
Stats are fixed as an extra bonus.


diff -Nrup drivers/net/r8169.c.orig drivers/net/r8169.c
--- drivers/net/r8169.c.orig	Thu Dec 18 03:58:50 2003
+++ drivers/net/r8169.c	Sat Feb 21 14:11:31 2004
@@ -871,7 +871,6 @@ rtl8169_tx_interrupt(struct net_device *
 		     void *ioaddr)
 {
 	unsigned long dirty_tx, tx_left = 0;
-	int entry = tp->cur_tx % NUM_TX_DESC;
 
 	assert(dev != NULL);
 	assert(tp != NULL);
@@ -881,14 +880,18 @@ rtl8169_tx_interrupt(struct net_device *
 	tx_left = tp->cur_tx - dirty_tx;
 
 	while (tx_left > 0) {
+		int entry = dirty_tx % NUM_TX_DESC;
+
 		if ((tp->TxDescArray[entry].status & OWNbit) == 0) {
-			dev_kfree_skb_irq(tp->
-					  Tx_skbuff[dirty_tx % NUM_TX_DESC]);
-			tp->Tx_skbuff[dirty_tx % NUM_TX_DESC] = NULL;
+			struct sk_buff *skb = tp->Tx_skbuff[entry];
+
+			tp->stats.tx_bytes += skb->len >= ETH_ZLEN ?
+					      skb->len : ETH_ZLEN;
 			tp->stats.tx_packets++;
+			dev_kfree_skb_irq(skb);
+			tp->Tx_skbuff[entry] = NULL;
 			dirty_tx++;
 			tx_left--;
-			entry++;
 		}
 	}
 

rtl8169 problem and 2.4.23

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

Hija,

I just discovered that the interface doesn't account outgoing bytes, so
although I'm shoveling GBs over NFS to another machine, ifconfig and
/proc/net/dev both state that the card hasn't transmitted anything:

eth2      Link encap:Ethernet  HWaddr 00:08:01:a3:64:97,
          inet addr:192.168.11.2  Bcast:192.168.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:297638 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1334930 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:45831863 (43.7 MiB)  TX bytes:0 (0.0 b)
          Interrupt:4 Base address:0xff00

Furthermore the performance is really scary slow: I'm not even getting 
100Base-T speeds from an Athlon XP to my G4 PowerBook under MacOS X over
a PtP connection.

What is interesting though is that the machine produces interrupt errors
which only occur when the card is active:

           CPU0
  0:  110545371          XT-PIC  timer
  1:          2          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  3:      35665          XT-PIC  ohci1394
  4:    4314949          XT-PIC  eth2
  8:          4          XT-PIC  rtc
 12:   87125964          XT-PIC  eth0
 14:    6035586          XT-PIC  ide0
 15:    6986897          XT-PIC  ide1
NMI:          0
LOC:  110544807
ERR:      10905
MIS:          0

And this is this output of the driver at initialisation:

r8169 Gigabit Ethernet driver 1.2 loaded
PCI: Found IRQ 4 for device 00:0d.0
r8169: PCI device 00:0d.0: unknown chip version, assuming RTL-8169
r8169: PCI device 00:0d.0: TxConfig = 0x800000
eth2: Identified chip type is 'RTL-8169'.
eth2: RealTek RTL8169 Gigabit Ethernet at 0xe093ff00, 00:08:01:a3:64:97, IRQ 4
eth2: Auto-negotiation Enabled.
eth2: 1000Mbps Full-duplex operation.

-- 
Servus,
       Daniel

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

[PATCH] Re: rtl8169 problem and 2.4.23

[Francois Romieu]

Daniel Egger <degger@fhm.edu> :
[r8169 stats broken]
> Furthermore the performance is really scary slow: I'm not even getting 
> 100Base-T speeds from an Athlon XP to my G4 PowerBook under MacOS X over
> a PtP connection.

Try the patch above. If it compiles, it should fix the stats and you get a
bugfix as an extra.

Please Cc: netdev@oss.sgi.com on followup.

--- linux-2.4.23.orig/drivers/net/r8169.c	Sun Jan 25 21:00:51 2004
+++ linux-2.4.23/drivers/net/r8169.c	Sun Jan 25 22:58:17 2004
@@ -874,7 +874,6 @@
 		     void *ioaddr)
 {
 	unsigned long dirty_tx, tx_left = 0;
-	int entry = tp->cur_tx % NUM_TX_DESC;
 
 	assert(dev != NULL);
 	assert(tp != NULL);
@@ -884,14 +883,18 @@
 	tx_left = tp->cur_tx - dirty_tx;
 
 	while (tx_left > 0) {
+		int entry = dirty_tx % NUM_TX_DESC;
+
 		if ((tp->TxDescArray[entry].status & OWNbit) == 0) {
-			dev_kfree_skb_irq(tp->
-					  Tx_skbuff[dirty_tx % NUM_TX_DESC]);
-			tp->Tx_skbuff[dirty_tx % NUM_TX_DESC] = NULL;
+			struct sk_buff *skb = tp->Tx_skbuff[entry];
+
+			tp->stats.tx_bytes += skb->len >= ETH_ZLEN ?
+					      skb->len : ETH_ZLEN;
 			tp->stats.tx_packets++;
+			dev_kfree_skb_irq(skb);
+			tp->Tx_skbuff[entry] = NULL;
 			dirty_tx++;
 			tx_left--;
-			entry++;
 		}
 	}
 

Re: [PATCH] Re: rtl8169 problem and 2.4.23

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]

On Jan 25, 2004, at 11:07 pm, Francois Romieu wrote:

> Try the patch above. If it compiles, it should fix the stats and you 
> get a
> bugfix as an extra.

Sorry for the delay. I've not had the chance to recompile the kernel
for my fileserver and restart it, yet. But in the meantime I've received
another card with RTL8169S and tried it in a different machine.

The current driver in 2.4.24 and 2.6.3 will lock up the box in almost
no time when under load (not a real kernel lockup but a soft one because
the machine is running over NFS and the driver seems to lose packets
and then rejects to transfer more). Your patch fixes this problem and 
the
counter issue for both 2.4.24 and 2.6.3, so it probably should go in 
ASAP.

However there's another thing bugging me: abysmal performance. In both
a switched and a direct environment the best I could get using netio
was 10MB/s send and 21MB/s receive, using NFS I get just under 10MB/s,
this is slower than with a 8139 el cheapo 100Mbit card.

The netio results are illogical anyway because the other side is the
fileserver, which has the same card, so if one end receives 21MB/s the
other end has to send equally as fast, no? :) The CPU utilization was
almost zero on server and client (both Athlon XP).

Servus,
       Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 478 bytes --]