kernel 2.4.22-1.2174.nptl has severe problems, when using r8169 driver and writing to nfs/afs. (long delays...) there could be the same problem in FC2 (2.6.3) The following patch from 2.4.26-pre2 corrects the problem: (tested on FC1/x86_64) -------------------- diff -ur linux-2.4.22-1.2174.nptl_37.rhfc1.at/drivers/net/r8169.c linux-2.4.25/drivers/net/r8169.c --- linux-2.4.22-1.2174.nptl_37.rhfc1.at/drivers/net/r8169.c 2004-03-06 10:10:09.000000000 +0100 +++ linux-2.4.25/drivers/net/r8169.c 2004-03-07 08:35:58.000000000 +0100 @@ -291,8 +291,8 @@ MODULE_AUTHOR("Realtek"); MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver"); -MODULE_LICENSE("GPL"); MODULE_PARM(media, "1-" __MODULE_STRING(MAX_UNITS) "i"); +MODULE_LICENSE("GPL"); static int rtl8169_open(struct net_device *dev); static int rtl8169_start_xmit(struct sk_buff *skb, struct net_device *dev); @@ -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++; } }
The r8169 driver with this patch works, however, there is still a problem. On transmit, the system cpu usage is almost 100%. It is the same for UDP or TCP. (checked with nttcp) I have also tried the backported patches from http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.4-rc2/ but the problem remains.
With 2.4.22-1.2129.nptl on AMD Duron (1300 MHz) I had severe problems with the following card: 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 12 I/O ports at a000 [size=256] Memory at e4800000 (32-bit, non-prefetchable) [size=256] Expansion ROM at <unassigned> [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Symptoms where throughput was not better than 900 kByte/sec on a 100 MBit/s connection. I grabbed r8169.c from kernel.orgs patch-2.4.27-pre5, commented out the SET_NETDEV_DEV-line, re- compiled and did rmmod, insmod of new r8169. System is now able to saturate 100 MBit/sec link (up to 12000 kByte/sec) with about 20% CPU. Upgrading the link to 1000 MBit/sec is planned later this year (new wiring needed).
Well, we're wired now. r8169 connected over cAT. 5E to KTI 4-port 1000-Base-T-Switch. Basically it works (still with 2.4.22-1.2129.nptl and r8169.c from patch-2.4.27-pre5 -- there hasn't been any notice about a fix in Fedora yet :(), but utilizing the card to the max (doing writes via NFS over this interface) the Kernel just crashes :( Unfortunately, I don't have any useful information via netlog: netlog: using network device <eth0> netlog: eth0's network driver does not implement netlogging yet, aborting. netlog: using network device <eth1> netlog: eth1's network driver does not implement netlogging yet, aborting. netlog: using network device <eth3> netlog: eth3's network driver does not implement netlogging yet, aborting. # Netgear FA311 (natsemi) alias eth0 natsemi # Realtek 10/100/1000 (r8169) alias eth1 r8169 # Intel EtherExpress Pro 100/S Dual (e100) alias eth2 e100 alias eth3 e100 Hmm, shouldn't e100 be supported by netlog?
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/