2.6.3 - 8139too timeout debug info

2.6.3 - 8139too timeout debug info

[Nick Warne]

Firstly, I am starting a fresh thread here, as I have subscribed to 
the lkml now so I can reply in a timely manner, and also the other 
thread was broke as I was replying 'off-list' - sorry about that.

OK, to recap.  With 2.6.3 I get timeouts with 8139too under network 
load (any load).  I have never had any problems with these _same_ two 
cards under any other kernel version over the last 3 years.

If I use the 8139too.c from 2.6.2, and build 2.6.3 with it, all works 
fine (I am running this version right now).

Here is the debuggered output (using #define RTL8139_NDEBUG 1):

#> /var/log/messages

Feb 27 17:12:27 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit 
timed out
Feb 27 17:12:39 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit 
timed out
Feb 27 17:12:42 Linux233 kernel: nfs: server 486Linux not responding, 
still trying
Feb 27 17:12:43 Linux233 kernel: nfs: server 486Linux not responding, 
still trying
Feb 27 17:12:51 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit 
timed out
Feb 27 17:12:51 Linux233 kernel: nfs: server 486Linux OK

Feb 27 17:12:51 Linux233 kernel: nfs: server 486Linux OK
Feb 27 17:13:03 Linux233 kernel: nfs: server 486Linux not responding, 
still trying
Feb 27 17:13:03 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit 
timed out
Feb 27 17:13:03 Linux233 kernel: nfs: server 486Linux OK

#> dmesg

NETDEV WATCHDOG: eth0: transmit timed out
eth0: Tx queue start entry 1314  dirty entry 1310.
eth0:  Tx descriptor 0 is 00002000.
eth0:  Tx descriptor 1 is 00002000.
eth0:  Tx descriptor 2 is 00002000. (queue head)
eth0:  Tx descriptor 3 is 00002000.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Tx queue start entry 1392  dirty entry 1388.
eth0:  Tx descriptor 0 is 00002000. (queue head)
eth0:  Tx descriptor 1 is 00002000.
eth0:  Tx descriptor 2 is 00002000.
eth0:  Tx descriptor 3 is 00002000.
nfs: server 486Linux not responding, still trying
nfs: server 486Linux not responding, still trying
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Tx queue start entry 363  dirty entry 359.
eth0:  Tx descriptor 0 is 00002000.
eth0:  Tx descriptor 1 is 00002000.
eth0:  Tx descriptor 2 is 00002000.
eth0:  Tx descriptor 3 is 00002000. (queue head)
nfs: server 486Linux OK
nfs: server 486Linux OK
nfs: server 486Linux not responding, still trying
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Tx queue start entry 3441  dirty entry 3437.
eth0:  Tx descriptor 0 is 00002000.
eth0:  Tx descriptor 1 is 00002000. (queue head)
eth0:  Tx descriptor 2 is 00002000.
eth0:  Tx descriptor 3 is 00002000.
nfs: server 486Linux OK

#> lspci

00:00.0 Host bridge: VIA Technologies, Inc. VT82C585VP [Apollo 
VP1/VPX] (rev 23)
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA 
[Apollo VP] (rev 27)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 02)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 
(rev 10)
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 
(rev 10)
00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W 
[Millennium II]

Built with:

# CONFIG_8139CP is not set
CONFIG_8139TOO=y
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_8139_RXBUF_IDX=2

Any more info required?

TIA,

Nick

-- 
"When you're chewing on life's gristle,
Don't grumble, Give a whistle
And this'll help things turn out for the best."

Re: 2.6.3 - 8139too timeout debug info

[Matt H.]

If your using acpi , boot up with either
acpi=ht
or
acpi=nopci


Matt H.

On Friday 27 February 2004 10:31 am, Nick Warne wrote:
> Firstly, I am starting a fresh thread here, as I have subscribed to
> the lkml now so I can reply in a timely manner, and also the other
> thread was broke as I was replying 'off-list' - sorry about that.
>
> OK, to recap.  With 2.6.3 I get timeouts with 8139too under network
> load (any load).  I have never had any problems with these _same_ two
> cards under any other kernel version over the last 3 years.
>
> If I use the 8139too.c from 2.6.2, and build 2.6.3 with it, all works
> fine (I am running this version right now).
>
> Here is the debuggered output (using #define RTL8139_NDEBUG 1):
>
> #> /var/log/messages
>
> Feb 27 17:12:27 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit
> timed out
> Feb 27 17:12:39 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit
> timed out
> Feb 27 17:12:42 Linux233 kernel: nfs: server 486Linux not responding,
> still trying
> Feb 27 17:12:43 Linux233 kernel: nfs: server 486Linux not responding,
> still trying
> Feb 27 17:12:51 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit
> timed out
> Feb 27 17:12:51 Linux233 kernel: nfs: server 486Linux OK
>
> Feb 27 17:12:51 Linux233 kernel: nfs: server 486Linux OK
> Feb 27 17:13:03 Linux233 kernel: nfs: server 486Linux not responding,
> still trying
> Feb 27 17:13:03 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit
> timed out
> Feb 27 17:13:03 Linux233 kernel: nfs: server 486Linux OK
>
> #> dmesg
>
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Tx queue start entry 1314  dirty entry 1310.
> eth0:  Tx descriptor 0 is 00002000.
> eth0:  Tx descriptor 1 is 00002000.
> eth0:  Tx descriptor 2 is 00002000. (queue head)
> eth0:  Tx descriptor 3 is 00002000.
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Tx queue start entry 1392  dirty entry 1388.
> eth0:  Tx descriptor 0 is 00002000. (queue head)
> eth0:  Tx descriptor 1 is 00002000.
> eth0:  Tx descriptor 2 is 00002000.
> eth0:  Tx descriptor 3 is 00002000.
> nfs: server 486Linux not responding, still trying
> nfs: server 486Linux not responding, still trying
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Tx queue start entry 363  dirty entry 359.
> eth0:  Tx descriptor 0 is 00002000.
> eth0:  Tx descriptor 1 is 00002000.
> eth0:  Tx descriptor 2 is 00002000.
> eth0:  Tx descriptor 3 is 00002000. (queue head)
> nfs: server 486Linux OK
> nfs: server 486Linux OK
> nfs: server 486Linux not responding, still trying
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Tx queue start entry 3441  dirty entry 3437.
> eth0:  Tx descriptor 0 is 00002000.
> eth0:  Tx descriptor 1 is 00002000. (queue head)
> eth0:  Tx descriptor 2 is 00002000.
> eth0:  Tx descriptor 3 is 00002000.
> nfs: server 486Linux OK
>
> #> lspci
>
> 00:00.0 Host bridge: VIA Technologies, Inc. VT82C585VP [Apollo
> VP1/VPX] (rev 23)
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA
> [Apollo VP] (rev 27)
> 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
> 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 02)
> 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139
> (rev 10)
> 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139
> (rev 10)
> 00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W
> [Millennium II]
>
> Built with:
>
> # CONFIG_8139CP is not set
> CONFIG_8139TOO=y
> # CONFIG_8139TOO_PIO is not set
> # CONFIG_8139TOO_TUNE_TWISTER is not set
> # CONFIG_8139TOO_8129 is not set
> # CONFIG_8139_OLD_RX_RESET is not set
> CONFIG_8139_RXBUF_IDX=2
>
> Any more info required?
>
> TIA,
>
> Nick

Re: 2.6.3 - 8139too timeout debug info

[Nick Warne]

> If your using acpi , boot up with either
> acpi=ht
> or
> acpi=nopci
> 
> 
> Matt H.

I do not have apci compiled.

# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set

Also I forgot to mention, 'noapic' makes no difference either.

Nick

-- 
"When you're chewing on life's gristle,
Don't grumble,
Give a whistle
And this'll help things turn out for the best."

Re: 2.6.3 - 8139too timeout debug info

[OGAWA Hirofumi]

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

"Nick Warne" <nick@ukfsn.org> writes:

> Firstly, I am starting a fresh thread here, as I have subscribed to 
> the lkml now so I can reply in a timely manner, and also the other 
> thread was broke as I was replying 'off-list' - sorry about that.
> 
> OK, to recap.  With 2.6.3 I get timeouts with 8139too under network 
> load (any load).  I have never had any problems with these _same_ two 
> cards under any other kernel version over the last 3 years.
> 
> If I use the 8139too.c from 2.6.2, and build 2.6.3 with it, all works 
> fine (I am running this version right now).

Interesting.

Please try the attached patch for debugging. After this problem
happen, send the all output of dmesg, all .config, and "cat /proc/interrupts".

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 8139too-debug.patch --]
[-- Type: text/x-patch, Size: 5288 bytes --]

---

 drivers/net/8139too.c |   56 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 56 insertions(+)

diff -puN drivers/net/8139too.c~8139too-debug drivers/net/8139too.c
--- linux-2.6.3/drivers/net/8139too.c~8139too-debug	2004-02-29 02:33:44.000000000 +0900
+++ linux-2.6.3-hirofumi/drivers/net/8139too.c	2004-02-29 02:37:45.000000000 +0900
@@ -718,6 +718,25 @@ static const unsigned int rtl8139_rx_con
 static const unsigned int rtl8139_tx_config =
 	(TX_DMA_BURST << TxDMAShift) | (TX_RETRY << TxRetryShift);
 
+#define RTL8139_DUMP(dev) do {						\
+	printk("%s: %s: run %d, stop %d\n", dev->name, __FUNCTION__,	\
+	       netif_running(dev), netif_queue_stopped(dev));		\
+	rtl8139_dump(dev->priv);					\
+} while(0)
+
+static void rtl8139_dump(struct rtl8139_private *tp)
+{
+	void *ioaddr = tp->mmio_addr;
+	int i;
+
+	for (i = 0; i < tp->regs_len; i++) {
+		if (i && (i % 16) == 0)
+			printk("\n");
+		printk("%02x ", RTL_R8(i));
+	}
+	printk("\n");
+}
+
 static void __rtl8139_cleanup_dev (struct net_device *dev)
 {
 	struct rtl8139_private *tp;
@@ -1355,6 +1374,10 @@ static int rtl8139_open (struct net_devi
 
 	rtl8139_start_thread(dev);
 
+	spin_lock_irq(&tp->lock);
+	RTL8139_DUMP(dev);
+	spin_unlock_irq(&tp->lock);
+
 	return 0;
 }
 
@@ -1673,6 +1696,11 @@ static void rtl8139_tx_timeout (struct n
 	u8 tmp8;
 	unsigned long flags;
 
+	printk("%s: irq %d\n", __FUNCTION__, irqs_disabled());
+	spin_lock_irq(&tp->lock);
+	RTL8139_DUMP(dev);
+	spin_unlock_irq(&tp->lock);
+
 	DPRINTK ("%s: Transmit timeout, status %2.2x %4.4x "
 		 "media %2.2x.\n", dev->name,
 		 RTL_R8 (ChipCmd),
@@ -1737,6 +1765,12 @@ static int rtl8139_start_xmit (struct sk
 	}
 
 	spin_lock_irq(&tp->lock);
+	{
+		u32 txstatus = RTL_R32(TxStatus0 + (entry * sizeof(u32)));
+		if (!(txstatus & TxStatOK) && (txstatus & TxUnderrun))
+			printk("8139too: durning re-transmit (%08x)\n",
+			       txstatus);
+	}
 	RTL_W32_F (TxStatus0 + (entry * sizeof (u32)),
 		   tp->tx_flag | max(len, (unsigned int)ETH_ZLEN));
 
@@ -1780,6 +1814,7 @@ static void rtl8139_tx_interrupt (struct
 
 		/* Note: TxCarrierLost is always asserted at 100mbps. */
 		if (txstatus & (TxOutOfWindow | TxAborted)) {
+			RTL8139_DUMP(dev);
 			/* There was an major error, log it. */
 			if (netif_msg_tx_err(tp))
 				printk(KERN_DEBUG "%s: Transmit error, Tx status %8.8x.\n",
@@ -1836,6 +1871,9 @@ static void rtl8139_rx_err (u32 rx_statu
 #ifdef CONFIG_8139_OLD_RX_RESET
 	int tmp_work;
 #endif
+	spin_lock_irq(&tp->lock);
+	RTL8139_DUMP(dev);
+	spin_unlock_irq(&tp->lock);
 
 	if (netif_msg_rx_err (tp)) 
 		printk(KERN_DEBUG "%s: Ethernet frame had errors, status %8.8x.\n",
@@ -2061,6 +2099,8 @@ static void rtl8139_weird_interrupt (str
 	assert (tp != NULL);
 	assert (ioaddr != NULL);
 
+	RTL8139_DUMP(dev);
+
 	/* Update the error count. */
 	tp->stats.rx_missed_errors += RTL_R32 (RxMissed);
 	RTL_W32 (RxMissed, 0);
@@ -2209,6 +2249,10 @@ static int rtl8139_close (struct net_dev
 	int ret = 0;
 	unsigned long flags;
 
+	spin_lock_irq(&tp->lock);
+	RTL8139_DUMP(dev);
+	spin_unlock_irq(&tp->lock);
+
 	netif_stop_queue (dev);
 
 	if (tp->thr_pid >= 0) {
@@ -2271,6 +2315,7 @@ static void rtl8139_get_wol(struct net_d
 	void *ioaddr = np->mmio_addr;
 
 	spin_lock_irq(&np->lock);
+	RTL8139_DUMP(dev);
 	if (rtl_chip_info[np->chipset].flags & HasLWake) {
 		u8 cfg3 = RTL_R8 (Config3);
 		u8 cfg5 = RTL_R8 (Config5);
@@ -2314,6 +2359,7 @@ static int rtl8139_set_wol(struct net_de
 		return -EINVAL;
 
 	spin_lock_irq(&np->lock);
+	RTL8139_DUMP(dev);
 	cfg3 = RTL_R8 (Config3) & ~(Cfg3_LinkUp | Cfg3_Magic);
 	if (wol->wolopts & WAKE_PHY)
 		cfg3 |= Cfg3_LinkUp;
@@ -2352,6 +2398,7 @@ static int rtl8139_get_settings(struct n
 {
 	struct rtl8139_private *np = dev->priv;
 	spin_lock_irq(&np->lock);
+	RTL8139_DUMP(dev);
 	mii_ethtool_gset(&np->mii, cmd);
 	spin_unlock_irq(&np->lock);
 	return 0;
@@ -2362,6 +2409,7 @@ static int rtl8139_set_settings(struct n
 	struct rtl8139_private *np = dev->priv;
 	int rc;
 	spin_lock_irq(&np->lock);
+	RTL8139_DUMP(dev);
 	rc = mii_ethtool_sset(&np->mii, cmd);
 	spin_unlock_irq(&np->lock);
 	return rc;
@@ -2370,12 +2418,14 @@ static int rtl8139_set_settings(struct n
 static int rtl8139_nway_reset(struct net_device *dev)
 {
 	struct rtl8139_private *np = dev->priv;
+	RTL8139_DUMP(dev);
 	return mii_nway_restart(&np->mii);
 }
 
 static u32 rtl8139_get_link(struct net_device *dev)
 {
 	struct rtl8139_private *np = dev->priv;
+	RTL8139_DUMP(dev);
 	return mii_link_ok(&np->mii);
 }
 
@@ -2409,6 +2459,7 @@ static void rtl8139_get_regs(struct net_
 	regs->version = RTL_REGS_VER;
 
 	spin_lock_irq(&np->lock);
+	RTL8139_DUMP(dev);
 	memcpy_fromio(regbuf, np->mmio_addr, regs->len);
 	spin_unlock_irq(&np->lock);
 }
@@ -2554,6 +2605,10 @@ static int rtl8139_suspend (struct pci_d
 	void *ioaddr = tp->mmio_addr;
 	unsigned long flags;
 
+	spin_lock_irqsave (&tp->lock, flags);
+	RTL8139_DUMP(dev);
+	spin_unlock_irqrestore (&tp->lock, flags);
+
 	if (!netif_running (dev))
 		return 0;
 
@@ -2583,6 +2638,7 @@ static int rtl8139_resume (struct pci_de
 	struct net_device *dev = pci_get_drvdata (pdev);
 	struct rtl8139_private *tp = dev->priv;
 
+	RTL8139_DUMP(dev);
 	if (!netif_running (dev))
 		return 0;
 	pci_restore_state (pdev, tp->pci_state);

_

Re: 2.6.3 - 8139too timeout debug info

[Nick Warne]

> > If I use the 8139too.c from 2.6.2, and build 2.6.3 with it, all works 
> > fine (I am running this version right now).
> 
> Interesting.
> 
> Please try the attached patch for debugging. After this problem
> happen, send the all output of dmesg, all .config, and "cat /proc/interrupts".
> 
> Thanks.
> -- 
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


Thanks for your help.  I have hell of a trouble doing this, as soon 
as any network load happens, the box becomes unresponsive during 
timeouts - but hopefully I have caught the info required.

http://www.linicks.net/8139too_debug/

Thanks,

Nick

-- 
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."

Re: 2.6.3 - 8139too timeout debug info

[OGAWA Hirofumi]

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

"Nick Warne" <nick@ukfsn.org> writes:

> Thanks for your help.  I have hell of a trouble doing this, as soon 
> as any network load happens, the box becomes unresponsive during 
> timeouts - but hopefully I have caught the info required.

Umm.. Looks like chip registers is normal, but TX/RX interrupt doesn't
happen. (BTW, there isn't rtl8139_open on debuginfo.txt. Was it already
scrolled?)

The following patch (incremental patch) is some part reverts to
2.6.2. Is behavior changed?

Please try 8139too-revert01.patch, and 8139too-revert02.patch.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 8139too-revert01.patch --]
[-- Type: text/x-patch, Size: 1214 bytes --]

---

 drivers/net/8139too.c |   13 +++++--------
 1 files changed, 5 insertions(+), 8 deletions(-)

diff -puN drivers/net/8139too.c~8139too-revert01 drivers/net/8139too.c
--- linux-2.6.3/drivers/net/8139too.c~8139too-revert01	2004-02-29 16:05:54.000000000 +0900
+++ linux-2.6.3-hirofumi/drivers/net/8139too.c	2004-02-29 16:29:41.000000000 +0900
@@ -2043,12 +2043,10 @@ static int rtl8139_rx(struct net_device 
 			skb_put (skb, pkt_size);
 
 			skb->protocol = eth_type_trans (skb, dev);
-
+			netif_rx (skb);
 			dev->last_rx = jiffies;
 			tp->stats.rx_bytes += pkt_size;
 			tp->stats.rx_packets++;
-
-			netif_receive_skb (skb);
 		} else {
 			if (net_ratelimit()) 
 				printk (KERN_WARNING
@@ -2204,11 +2202,10 @@ static irqreturn_t rtl8139_interrupt (in
 
 	/* Receive packets are processed by poll routine.
 	   If not running start it now. */
-	if (status & RxAckBits){
-		if (netif_rx_schedule_prep(dev)) {
-			RTL_W16_F (IntrMask, rtl8139_norx_intr_mask);
-			__netif_rx_schedule (dev);
-		}
+	if (status & RxAckBits) {
+		RTL_W16_F(IntrMask, rtl8139_norx_intr_mask);
+		rtl8139_rx(dev, tp, dev->weight);
+		RTL_W16_F(IntrMask, rtl8139_intr_mask);
 	}
 
 	/* Check uncommon events with one test. */

_

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 8139too-revert02.patch --]
[-- Type: text/x-patch, Size: 1012 bytes --]

---

 drivers/net/8139too.c |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

diff -puN drivers/net/8139too.c~8139too-revert02 drivers/net/8139too.c
--- linux-2.6.3/drivers/net/8139too.c~8139too-revert02	2004-02-29 16:30:14.000000000 +0900
+++ linux-2.6.3-hirofumi/drivers/net/8139too.c	2004-02-29 16:33:35.000000000 +0900
@@ -1374,6 +1374,7 @@ static int rtl8139_open (struct net_devi
 
 	rtl8139_start_thread(dev);
 
+	printk("%s: revert02\n", dev->name);
 	spin_lock_irq(&tp->lock);
 	RTL8139_DUMP(dev);
 	spin_unlock_irq(&tp->lock);
@@ -2202,11 +2203,8 @@ static irqreturn_t rtl8139_interrupt (in
 
 	/* Receive packets are processed by poll routine.
 	   If not running start it now. */
-	if (status & RxAckBits) {
-		RTL_W16_F(IntrMask, rtl8139_norx_intr_mask);
+	if (status & RxAckBits)
 		rtl8139_rx(dev, tp, dev->weight);
-		RTL_W16_F(IntrMask, rtl8139_intr_mask);
-	}
 
 	/* Check uncommon events with one test. */
 	if (unlikely(status & (PCIErr | PCSTimeout | RxUnderrun | RxErr)))

_

Re: 2.6.3 - 8139too timeout debug info

[OGAWA Hirofumi]

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

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

> "Nick Warne" <nick@ukfsn.org> writes:
> 
> > Thanks for your help.  I have hell of a trouble doing this, as soon 
> > as any network load happens, the box becomes unresponsive during 
> > timeouts - but hopefully I have caught the info required.
> 
> Umm.. Looks like chip registers is normal, but TX/RX interrupt doesn't
> happen. (BTW, there isn't rtl8139_open on debuginfo.txt. Was it already
> scrolled?)
> 
> The following patch (incremental patch) is some part reverts to
> 2.6.2. Is behavior changed?

Oops, wrong patches. Please try these.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 8139too-revert01.patch --]
[-- Type: text/x-patch, Size: 1429 bytes --]

---

 drivers/net/8139too.c |   14 ++++++--------
 1 files changed, 6 insertions(+), 8 deletions(-)

diff -puN drivers/net/8139too.c~8139too-revert01 drivers/net/8139too.c
--- linux-2.6.3/drivers/net/8139too.c~8139too-revert01	2004-02-29 17:02:32.000000000 +0900
+++ linux-2.6.3-hirofumi/drivers/net/8139too.c	2004-02-29 17:02:59.000000000 +0900
@@ -1374,6 +1374,7 @@ static int rtl8139_open (struct net_devi
 
 	rtl8139_start_thread(dev);
 
+	printk("%s: revert01\n", dev->name);
 	spin_lock_irq(&tp->lock);
 	RTL8139_DUMP(dev);
 	spin_unlock_irq(&tp->lock);
@@ -2043,12 +2044,10 @@ static int rtl8139_rx(struct net_device 
 			skb_put (skb, pkt_size);
 
 			skb->protocol = eth_type_trans (skb, dev);
-
+			netif_rx (skb);
 			dev->last_rx = jiffies;
 			tp->stats.rx_bytes += pkt_size;
 			tp->stats.rx_packets++;
-
-			netif_receive_skb (skb);
 		} else {
 			if (net_ratelimit()) 
 				printk (KERN_WARNING
@@ -2204,11 +2203,10 @@ static irqreturn_t rtl8139_interrupt (in
 
 	/* Receive packets are processed by poll routine.
 	   If not running start it now. */
-	if (status & RxAckBits){
-		if (netif_rx_schedule_prep(dev)) {
-			RTL_W16_F (IntrMask, rtl8139_norx_intr_mask);
-			__netif_rx_schedule (dev);
-		}
+	if (status & RxAckBits) {
+		RTL_W16_F(IntrMask, rtl8139_norx_intr_mask);
+		rtl8139_rx(dev, tp, dev->weight);
+		RTL_W16_F(IntrMask, rtl8139_intr_mask);
 	}
 
 	/* Check uncommon events with one test. */

_

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 8139too-revert02.patch --]
[-- Type: text/x-patch, Size: 1052 bytes --]

---

 drivers/net/8139too.c |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff -puN drivers/net/8139too.c~8139too-revert02 drivers/net/8139too.c
--- linux-2.6.3/drivers/net/8139too.c~8139too-revert02	2004-02-29 17:04:38.000000000 +0900
+++ linux-2.6.3-hirofumi/drivers/net/8139too.c	2004-02-29 17:04:58.000000000 +0900
@@ -1374,7 +1374,7 @@ static int rtl8139_open (struct net_devi
 
 	rtl8139_start_thread(dev);
 
-	printk("%s: revert01\n", dev->name);
+	printk("%s: revert02\n", dev->name);
 	spin_lock_irq(&tp->lock);
 	RTL8139_DUMP(dev);
 	spin_unlock_irq(&tp->lock);
@@ -2203,11 +2203,8 @@ static irqreturn_t rtl8139_interrupt (in
 
 	/* Receive packets are processed by poll routine.
 	   If not running start it now. */
-	if (status & RxAckBits) {
-		RTL_W16_F(IntrMask, rtl8139_norx_intr_mask);
+	if (status & RxAckBits)
 		rtl8139_rx(dev, tp, dev->weight);
-		RTL_W16_F(IntrMask, rtl8139_intr_mask);
-	}
 
 	/* Check uncommon events with one test. */
 	if (unlikely(status & (PCIErr | PCSTimeout | RxUnderrun | RxErr)))

_

Re: 2.6.3 - 8139too timeout debug info

[Nick Warne]

> > Umm.. Looks like chip registers is normal, but TX/RX interrupt doesn't
> > happen. (BTW, there isn't rtl8139_open on debuginfo.txt. Was it already
> > scrolled?)
> > 
> > The following patch (incremental patch) is some part reverts to
> > 2.6.2. Is behavior changed?
> 
> Oops, wrong patches. Please try these.

OK, I applied patch01 first - same problems.  Then I applied patch02 
_over_ patch01.  Still same results.

I am not sure if you meant me to apply over the first debug patch you 
sent?  Here, I just applied to standard 2.6.3 > 8139too.c file with 
RTL8139_NDEBUG 1 set.

With these patched dmesg gets flooded - and I have real trouble 
trying to do anything on the box with the timeout issues.

http://www.linicks.net/8139too_debug/patch01_02_info.txt

Thanks,

Nick

-- 
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."

Re: 2.6.3 - 8139too timeout debug info

[Nick Warne]

 > Please try,
> 
> 	8139too-debug + 8139too-revert01
> 
> and if it still is the same,
> 
> 	8139too-debug + 8139too-revert01 + 8139too-revert02
> 

OK, I have patched as asked, and still get the problem.

Information here, 2 new files:

http://www.linicks.net/8139too_debug/

debug_with_patch01.txt

&

debug_with_patch01_patch02.txt

Thank you for your time in this.

Nick

-- 
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."

Re: 2.6.3 - 8139too timeout debug info

[OGAWA Hirofumi]

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

"Nick Warne" <nick@ukfsn.org> writes:

> OK, I have patched as asked, and still get the problem.
> 
> Information here, 2 new files:
> 
> http://www.linicks.net/8139too_debug/
> 
> debug_with_patch01.txt
> 
> &
> 
> debug_with_patch01_patch02.txt

Thanks. Umm.. strange, already NAPI reverted.
Does these patches change the behavior?


debug + revert01 + revert02 + revert03

after

debug + revert01 + revert02 + revert03 + revert04

-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 8139too-revert03.patch --]
[-- Type: text/x-patch, Size: 1081 bytes --]

---

 drivers/net/8139too.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletion(-)

diff -puN drivers/net/8139too.c~8139too-revert03 drivers/net/8139too.c
--- linux-2.6.4-rc1/drivers/net/8139too.c~8139too-revert03	2004-02-29 20:35:21.000000000 +0900
+++ linux-2.6.4-rc1-hirofumi/drivers/net/8139too.c	2004-02-29 21:29:49.000000000 +0900
@@ -1374,7 +1374,7 @@ static int rtl8139_open (struct net_devi
 
 	rtl8139_start_thread(dev);
 
-	printk("%s: revert02\n", dev->name);
+	printk("%s: revert03\n", dev->name);
 	spin_lock_irq(&tp->lock);
 	RTL8139_DUMP(dev);
 	spin_unlock_irq(&tp->lock);
@@ -2172,8 +2172,11 @@ static irqreturn_t rtl8139_interrupt (in
 	u16 status, ackstat;
 	int link_changed = 0; /* avoid bogus "uninit" warning */
 	int handled = 0;
+	int boguscnt = 20;
 
 	spin_lock (&tp->lock);
+	do {
+
 	status = RTL_R16 (IntrStatus);
 
 	/* shared irq? */
@@ -2216,6 +2219,9 @@ static irqreturn_t rtl8139_interrupt (in
 		if (status & TxErr)
 			RTL_W16 (IntrStatus, TxErr);
 	}
+
+		boguscnt--;
+	} while(boguscnt > 0);
  out:
 	spin_unlock (&tp->lock);
 

_

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 8139too-revert04.patch --]
[-- Type: text/x-patch, Size: 1042 bytes --]

---

 drivers/net/8139too.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletion(-)

diff -puN drivers/net/8139too.c~8139too-revert04 drivers/net/8139too.c
--- linux-2.6.4-rc1/drivers/net/8139too.c~8139too-revert04	2004-02-29 21:30:19.000000000 +0900
+++ linux-2.6.4-rc1-hirofumi/drivers/net/8139too.c	2004-02-29 21:31:05.000000000 +0900
@@ -1374,7 +1374,7 @@ static int rtl8139_open (struct net_devi
 
 	rtl8139_start_thread(dev);
 
-	printk("%s: revert03\n", dev->name);
+	printk("%s: revert04\n", dev->name);
 	spin_lock_irq(&tp->lock);
 	RTL8139_DUMP(dev);
 	spin_unlock_irq(&tp->lock);
@@ -2225,6 +2225,14 @@ static irqreturn_t rtl8139_interrupt (in
  out:
 	spin_unlock (&tp->lock);
 
+	if (boguscnt <= 0) {
+		printk (KERN_WARNING "%s: Too much work at interrupt, "
+			"IntrStatus=0x%4.4x.\n", dev->name, status);
+
+		/* Clear all interrupt sources. */
+		RTL_W16 (IntrStatus, 0xffff);
+	}
+
 	DPRINTK ("%s: exiting interrupt, intr_status=%#4.4x.\n",
 		 dev->name, RTL_R16 (IntrStatus));
 	return IRQ_RETVAL(handled);

_

Re: 2.6.3 - 8139too timeout debug info

[Nick Warne]

> Thanks. Umm.. strange, already NAPI reverted.
> Does these patches change the behavior?
> 
> 
> debug + revert01 + revert02 + revert03

**BINGO**

Excellent.  patch03 has stopped the timeouts.  I have just tested.  I 
moved (via ftp) a 30MB file from network -> eth0, and at the same 
time downloaded a 30MB file (via httpd) from the Internet -> eth1.

I was getting 10Mbs internal, and 30Kbs external (as expected).  NO 
TIMEOUTS :) :)

Before, just the internal FTP timed out in 5 seconds.

dmesg is basically very quiet:

http://www.linicks.net/8139too_debug/bingo.txt

> after
> 
> debug + revert01 + revert02 + revert03 + revert04

I haven't applied patch04.

I will continue to run the debug kernel.

Thank you :)

Nick

-- 
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."

Re: 2.6.3 - 8139too timeout debug info

[OGAWA Hirofumi]

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

"Nick Warne" <nick@ukfsn.org> writes:

> > Thanks. Umm.. strange, already NAPI reverted.
> > Does these patches change the behavior?
> > 
> > debug + revert01 + revert02 + revert03
> 
> **BINGO**
> 
> Excellent.  patch03 has stopped the timeouts.  I have just tested.  I 
> moved (via ftp) a 30MB file from network -> eth0, and at the same 
> time downloaded a 30MB file (via httpd) from the Internet -> eth1.
> 
> I was getting 10Mbs internal, and 30Kbs external (as expected).  NO 
> TIMEOUTS :) :)
> 
> Before, just the internal FTP timed out in 5 seconds.
> 
> dmesg is basically very quiet:
> 
> http://www.linicks.net/8139too_debug/bingo.txt
> 
> > after
> > 
> > debug + revert01 + revert02 + revert03 + revert04
> 
> I haven't applied patch04.
> 
> I will continue to run the debug kernel.

Ok, thanks for debugging. Looks like this problem is not 8139too.
And same problem should happen with the old driver (probably, it appear
with "max_interrupt_work=1").

Umm... I guess this problem is miss config of Edge/Level-Trigger or
something.  Sorry, I don't know detail.


Jeff, I think CONFIG_8139TOO_NAPI is useful for now.
What do you think of these? Any idea?

8139too-config-napi.patch      - add CONFIG_8139TOO_NAPI
                                 (dirty #ifdef, the cleanup may be needed)
8139too-useful-txtimeout.patch - more debug info for rtl8139_tx_timeout()

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 8139too-config-napi.patch --]
[-- Type: text/x-patch, Size: 6388 bytes --]


[PATCH] 8139too: add CONFIG_8139TOO_NAPI

This patch adds the CONFIG_8139TOO_NAPI.


---

 drivers/net/8139too.c |  102 ++++++++++++++++++++++++++++++++++++++++++++++++--
 drivers/net/Kconfig   |    4 +
 2 files changed, 102 insertions(+), 4 deletions(-)

diff -puN drivers/net/8139too.c~8139too-config-napi drivers/net/8139too.c
--- linux-2.6.4-rc1/drivers/net/8139too.c~8139too-config-napi	2004-03-01 01:46:55.000000000 +0900
+++ linux-2.6.4-rc1-hirofumi/drivers/net/8139too.c	2004-03-01 02:54:46.000000000 +0900
@@ -159,6 +159,11 @@
 static int media[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1};
 static int full_duplex[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1};
 
+#ifndef CONFIG_8139TOO_NAPI
+/* Maximum events (Rx packets, etc.) to handle at each interrupt. */
+static int max_interrupt_work = 20;
+#endif
+
 /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
    The RTL chips use a 64 element hash table based on the Ethernet CRC.  */
 static int multicast_filter_limit = 32;
@@ -592,6 +597,10 @@ MODULE_AUTHOR ("Jeff Garzik <jgarzik@pob
 MODULE_DESCRIPTION ("RealTek RTL-8139 Fast Ethernet driver");
 MODULE_LICENSE("GPL");
 
+#ifndef CONFIG_8139TOO_NAPI
+MODULE_PARM (max_interrupt_work, "i");
+MODULE_PARM_DESC (max_interrupt_work, "8139too maximum events handled per interrupt");
+#endif
 MODULE_PARM (multicast_filter_limit, "i");
 MODULE_PARM (media, "1-" __MODULE_STRING(MAX_UNITS) "i");
 MODULE_PARM (full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i");
@@ -611,7 +620,9 @@ static void rtl8139_tx_timeout (struct n
 static void rtl8139_init_ring (struct net_device *dev);
 static int rtl8139_start_xmit (struct sk_buff *skb,
 			       struct net_device *dev);
+#ifdef CONFIG_8139TOO_NAPI
 static int rtl8139_poll(struct net_device *dev, int *budget);
+#endif
 #ifdef CONFIG_NET_POLL_CONTROLLER
 static void rtl8139_poll_controller(struct net_device *dev);
 #endif
@@ -983,8 +994,10 @@ static int __devinit rtl8139_init_one (s
 	/* The Rtl8139-specific entries in the device structure. */
 	dev->open = rtl8139_open;
 	dev->hard_start_xmit = rtl8139_start_xmit;
+#ifdef CONFIG_8139TOO_NAPI
 	dev->poll = rtl8139_poll;
 	dev->weight = 64;
+#endif
 	dev->stop = rtl8139_close;
 	dev->get_stats = rtl8139_get_stats;
 	dev->set_multicast_list = rtl8139_set_rx_mode;
@@ -1938,7 +1951,10 @@ static int rtl8139_rx(struct net_device 
 		 RTL_R16 (RxBufAddr),
 		 RTL_R16 (RxBufPtr), RTL_R8 (ChipCmd));
 
-	while (netif_running(dev) && received < budget 
+	while (netif_running(dev)
+#ifdef CONFIG_8139TOO_NAPI
+	       && received < budget
+#endif
 	       && (RTL_R8 (ChipCmd) & RxBufEmpty) == 0) {
 		u32 ring_offset = cur_rx % RX_BUF_LEN;
 		u32 rx_status;
@@ -2009,8 +2025,11 @@ static int rtl8139_rx(struct net_device 
 			dev->last_rx = jiffies;
 			tp->stats.rx_bytes += pkt_size;
 			tp->stats.rx_packets++;
-
+#ifdef CONFIG_8139TOO_NAPI
 			netif_receive_skb (skb);
+#else
+			netif_rx (skb);
+#endif
 		} else {
 			if (net_ratelimit()) 
 				printk (KERN_WARNING
@@ -2088,6 +2107,7 @@ static void rtl8139_weird_interrupt (str
 	}
 }
 
+#ifdef CONFIG_8139TOO_NAPI
 static int rtl8139_poll(struct net_device *dev, int *budget)
 {
 	struct rtl8139_private *tp = dev->priv;
@@ -2138,13 +2158,13 @@ static irqreturn_t rtl8139_interrupt (in
 	status = RTL_R16 (IntrStatus);
 
 	/* shared irq? */
-	if (unlikely((status & rtl8139_intr_mask) == 0)) 
+	if (unlikely((status & rtl8139_intr_mask) == 0))
 		goto out;
 
 	handled = 1;
 
 	/* h/w no longer present (hotplug?) or major error, bail */
-	if (unlikely(status == 0xFFFF)) 
+	if (unlikely(status == 0xFFFF))
 		goto out;
 
 	/* close possible race's with dev_close */
@@ -2188,6 +2208,80 @@ static irqreturn_t rtl8139_interrupt (in
 		 dev->name, RTL_R16 (IntrStatus));
 	return IRQ_RETVAL(handled);
 }
+#else /* !CONFIG_8139TOO_NAPI */
+static irqreturn_t rtl8139_interrupt (int irq, void *dev_instance,
+			       struct pt_regs *regs)
+{
+	struct net_device *dev = (struct net_device *) dev_instance;
+	struct rtl8139_private *tp = dev->priv;
+	int boguscnt = max_interrupt_work;
+	void *ioaddr = tp->mmio_addr;
+	u16 status, ackstat;
+	int link_changed = 0; /* avoid bogus "uninit" warning */
+	int handled = 0;
+
+	spin_lock (&tp->lock);
+
+	do {
+		status = RTL_R16 (IntrStatus);
+
+		/* shared irq? */
+		if (unlikely((status & rtl8139_intr_mask) == 0))
+			goto out;
+
+		handled = 1;
+
+		/* h/w no longer present (hotplug?) or major error, bail */
+		if (unlikely(status == 0xFFFF))
+			goto out;
+
+		/* close possible race's with dev_close */
+		if (unlikely(!netif_running(dev))) {
+			RTL_W16 (IntrMask, 0);
+			goto out;
+		}
+
+		/* Acknowledge all of the current interrupt sources ASAP, but
+		   an first get an additional status bit from CSCR. */
+		if (unlikely(status & RxUnderrun))
+			link_changed = RTL_R16 (CSCR) & CSCR_LinkChangeBit;
+
+		ackstat = status & ~(RxAckBits | TxErr);
+		if (ackstat)
+			RTL_W16 (IntrStatus, ackstat);
+
+		if (status & RxAckBits)
+			rtl8139_rx (dev, tp, 0);
+
+		/* Check uncommon events with one test. */
+		if (unlikely(status & (PCIErr|PCSTimeout|RxUnderrun|RxErr)))
+			rtl8139_weird_interrupt (dev, tp, ioaddr,
+						 status, link_changed);
+
+		if (status & (TxOK | TxErr)) {
+			rtl8139_tx_interrupt (dev, tp, ioaddr);
+			if (status & TxErr)
+				RTL_W16 (IntrStatus, TxErr);
+		}
+
+		boguscnt--;
+	} while (boguscnt > 0);
+ out:
+	if (boguscnt <= 0) {
+		printk (KERN_WARNING "%s: Too much work at interrupt, "
+			"IntrStatus=0x%4.4x.\n", dev->name, status);
+
+		/* Clear all interrupt sources. */
+		RTL_W16 (IntrStatus, 0xffff);
+	}
+
+	spin_unlock (&tp->lock);
+
+	DPRINTK ("%s: exiting interrupt, intr_status=%#4.4x.\n",
+		 dev->name, RTL_R16 (IntrStatus));
+	return IRQ_RETVAL(handled);
+}
+#endif /* !CONFIG_8139TOO_NAPI */
 
 #ifdef CONFIG_NET_POLL_CONTROLLER
 /*
diff -puN drivers/net/Kconfig~8139too-config-napi drivers/net/Kconfig
--- linux-2.6.4-rc1/drivers/net/Kconfig~8139too-config-napi	2004-03-01 01:46:55.000000000 +0900
+++ linux-2.6.4-rc1-hirofumi/drivers/net/Kconfig	2004-03-01 01:46:55.000000000 +0900
@@ -1543,6 +1543,10 @@ config 8139TOO
 	  To compile this driver as a module, choose M here: the module
 	  will be called 8139too.  This is recommended.
 
+config 8139TOO_NAPI
+	bool "Use Rx Polling (NAPI)"
+	depends on 8139TOO
+
 config 8139TOO_PIO
 	bool "Use PIO instead of MMIO"
 	default y

_

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 8139too-useful-txtimeout.patch --]
[-- Type: text/x-patch, Size: 2435 bytes --]


[PATCH] 8139too: more useful debug info for tx_timeout

	/* disable Tx ASAP, if not already */
	tmp8 = RTL_R8 (ChipCmd);
	if (tmp8 & CmdTxEnb)
		RTL_W8 (ChipCmd, CmdRxEnb);

The above will clear the Tx Descs. So, this prints the debugging info
before rtl8139_tx_timeout() does it. And IntrStatus etc. also prints
anytime for the debug.


---

 drivers/net/8139too.c |   28 +++++++++++++---------------
 1 files changed, 13 insertions(+), 15 deletions(-)

diff -puN drivers/net/8139too.c~8139too-useful-txtimeout drivers/net/8139too.c
--- linux-2.6.4-rc1/drivers/net/8139too.c~8139too-useful-txtimeout	2004-03-01 02:54:54.000000000 +0900
+++ linux-2.6.4-rc1-hirofumi/drivers/net/8139too.c	2004-03-01 02:54:54.000000000 +0900
@@ -1686,11 +1686,19 @@ static void rtl8139_tx_timeout (struct n
 	u8 tmp8;
 	unsigned long flags;
 
-	DPRINTK ("%s: Transmit timeout, status %2.2x %4.4x "
-		 "media %2.2x.\n", dev->name,
-		 RTL_R8 (ChipCmd),
-		 RTL_R16 (IntrStatus),
-		 RTL_R8 (MediaStatus));
+	spin_lock(&tp->rx_lock);
+	printk (KERN_DEBUG "%s: Transmit timeout, status %2.2x %4.4x %4.4x "
+		"media %2.2x.\n", dev->name, RTL_R8 (ChipCmd),
+		RTL_R16(IntrStatus), RTL_R16(IntrMask), RTL_R8(MediaStatus));
+	/* Emit info to figure out what went wrong. */
+	printk (KERN_DEBUG "%s: Tx queue start entry %ld  dirty entry %ld.\n",
+		dev->name, tp->cur_tx, tp->dirty_tx);
+	for (i = 0; i < NUM_TX_DESC; i++)
+		printk (KERN_DEBUG "%s:  Tx descriptor %d is %8.8lx.%s\n",
+			dev->name, i, RTL_R32 (TxStatus0 + (i * 4)),
+			i == tp->dirty_tx % NUM_TX_DESC ?
+				" (queue head)" : "");
+	spin_unlock(&tp->rx_lock);
 
 	tp->xstats.tx_timeouts++;
 
@@ -1703,15 +1711,6 @@ static void rtl8139_tx_timeout (struct n
 	/* Disable interrupts by clearing the interrupt mask. */
 	RTL_W16 (IntrMask, 0x0000);
 
-	/* Emit info to figure out what went wrong. */
-	printk (KERN_DEBUG "%s: Tx queue start entry %ld  dirty entry %ld.\n",
-		dev->name, tp->cur_tx, tp->dirty_tx);
-	for (i = 0; i < NUM_TX_DESC; i++)
-		printk (KERN_DEBUG "%s:  Tx descriptor %d is %8.8lx.%s\n",
-			dev->name, i, RTL_R32 (TxStatus0 + (i * 4)),
-			i == tp->dirty_tx % NUM_TX_DESC ?
-				" (queue head)" : "");
-
 	/* Stop a shared interrupt from scavenging while we are. */
 	spin_lock_irqsave (&tp->lock, flags);
 	rtl8139_tx_clear (tp);
@@ -1723,7 +1722,6 @@ static void rtl8139_tx_timeout (struct n
 		netif_wake_queue (dev);
 	}
 	spin_unlock(&tp->rx_lock);
-	
 }
 
 

_

Re: 2.6.3 - 8139too timeout debug info

[Nick Warne]

> Ok, thanks for debugging. Looks like this problem is not 8139too.
> And same problem should happen with the old driver (probably, it appear
> with "max_interrupt_work=1").
> 
> Umm... I guess this problem is miss config of Edge/Level-Trigger or
> something.  Sorry, I don't know detail.

Well, after running whatever patches you supplied for me to test, I 
can confirm after running it for 30 hours, it works a treat - and 
without having any true measuring devices on network performance, I 
can tell you it is very much faster and responsive all round... on 
downloads, web browsing, FTP - everything.  (as you do say, I did 
used to get pauses sometimes during large file movement/downloads 
etc., but just thought it was normal network activity - I do not get 
them any more!).

Insomuchso I have kept this debug 8139too.c build as a running kernel 
now.

Thank you,

Nick

-- 
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."

Re: 2.6.3 - 8139too timeout debug info

[Jeff Garzik]

What was the final resolution of the 8139too debugging?

Re: 2.6.3 - 8139too timeout debug info

[OGAWA Hirofumi]

Jeff Garzik <jgarzik@pobox.com> writes:

> What was the final resolution of the 8139too debugging?

http://marc.theaimsgroup.com/?l=linux-kernel&m=107919285122190&w=2

The cause of his problem was BIOS configuration. It was edge-trigger.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: 2.6.3 - 8139too timeout debug info

[Christian Gut]

On Tue, 23 Mar 2004, OGAWA Hirofumi wrote:

> Jeff Garzik <jgarzik@pobox.com> writes:
> > What was the final resolution of the 8139too debugging?
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107919285122190&w=2
> The cause of his problem was BIOS configuration. It was edge-trigger.

not sure if that was the only reason. 2.6.3 and everything up breaks the
rtl nic in my laptop and i cant configure anything like edge-trigger in
my bios.

The nic works without problems when i use 2.6.2 version of 8139too.c. Is
there any possibility to get these or similar patches into 2.6.5 to
support a config option to get the old behavior?

Re: 2.6.3 - 8139too timeout debug info

[OGAWA Hirofumi]

Christian Gut <cycloon@is-root.org> writes:

> On Tue, 23 Mar 2004, OGAWA Hirofumi wrote:
> 
> > Jeff Garzik <jgarzik@pobox.com> writes:
> > > What was the final resolution of the 8139too debugging?
> > 
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=107919285122190&w=2
> > The cause of his problem was BIOS configuration. It was edge-trigger.
> 
> not sure if that was the only reason. 2.6.3 and everything up breaks the
> rtl nic in my laptop and i cant configure anything like edge-trigger in
> my bios.

Could you please tell more detail, what happened?
And please send the /proc/interrupt, dmesg, lspci -vvvxxx.

> The nic works without problems when i use 2.6.2 version of 8139too.c. Is
> there any possibility to get these or similar patches into 2.6.5 to
> support a config option to get the old behavior?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: 2.6.3 - 8139too timeout debug info

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

> Christian Gut <cycloon@is-root.org> writes:
> 
> > On Tue, 23 Mar 2004, OGAWA Hirofumi wrote:
> > 
> > > Jeff Garzik <jgarzik@pobox.com> writes:
> > > > What was the final resolution of the 8139too debugging?
> > > 
> > > http://marc.theaimsgroup.com/?l=linux-kernel&m=107919285122190&w=2
> > > The cause of his problem was BIOS configuration. It was edge-trigger.
> > 
> > not sure if that was the only reason. 2.6.3 and everything up breaks the
> > rtl nic in my laptop and i cant configure anything like edge-trigger in
> > my bios.

This problem was also edge-triggered interrupt. In his case, ACPI
enable fixes it.

Looks like APCI does the following in acpi_pci_irq_enable(),

	/* 
	 * Make sure all (legacy) PCI IRQs are set as level-triggered.
	 */
#ifdef CONFIG_X86
	{
		static u16 irq_mask;
		if ((dev->irq < 16) &&  !((1 << dev->irq) & irq_mask)) {
			ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Setting IRQ %d as level-triggered\n", dev->irq));
			irq_mask |= (1 << dev->irq);
			eisa_set_level_irq(dev->irq);
		}
	}
#endif

This one is useful as workaround. But I think eisa_set_level_irq() is
not enough for doing this, because looks like the some chips needs
additional setting.

Probably we need the proper interface... Ummm..
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: 2.6.3 - 8139too timeout debug info

[Nick Warne]

Sorry, I replied to Jeff only.  This is just for history and close 
this thread.


> > What was the final resolution of the 8139too debugging?
> 
> Hi Jeff,
> 
> Yes it was.  I did post to the list the resolution in my case:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107919285122190&w=2
> 
> Thanks,
> 
> Nick :)
> 

-- 
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."