linux-kernel - Re: [bug?] r8169: hangs under heavy load

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111127231147.GA1784@electric-eye.fr.zoreil.com>
Date:	Mon, 28 Nov 2011 00:11:47 +0100
From:	Francois Romieu <romieu@...zoreil.com>
To:	booster@...ke7.net
Cc:	Jonathan Nieder <jrnieder@...il.com>,
	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
	nic_swsd@...ltek.com, linux-kernel@...r.kernel.org,
	Armin Kazmi <armin.kazmi@...dortmund.de>,
	Hayes Wang <hayeswang@...ltek.com>
Subject: Re: [bug?] r8169: hangs under heavy load

booster@...ke7.net <booster@...ke7.net> :
[...]
> Jonathan, I compiled a new kernel with the patch described above but the
> behavior is still the same. During high network load the link hangs:
> 
> [  195.332478] r8169 0000:02:00.0: eth0: link up
> [  222.517171] r8169 0000:02:00.0: eth0: link up
> [  222.908277] r8169 0000:02:00.0: eth0: link up
> [  223.508249] r8169 0000:02:00.0: eth0: link up

It does recover, doesn't it ?

> Is there a way to activate more driver debugging in the kernel ?

You can lower the delay in rtl8169_schedule_work (4) but it is akin
to papering over the issue.

You may try the stuff below in place of the current patch. I will not
be surprized if the link really hangs (no crash but no traffic).

Hayes, does the 8168c require something special to recover from Rx FIFO
overflow ?

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 6f06aa1..e937737 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -427,6 +427,7 @@ enum rtl_register_content {
 	/* InterruptStatusBits */
 	SYSErr		= 0x8000,
 	PCSTimeout	= 0x4000,
+	RxFIFOEmpty	= 0x0200,
 	SWInt		= 0x0100,
 	TxDescUnavail	= 0x0080,
 	RxFIFOOver	= 0x0040,
@@ -5815,15 +5816,27 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
 		}
 
 		if (unlikely(status & RxFIFOOver)) {
+			int i;
+
 			switch (tp->mac_version) {
 			/* Work around for rx fifo overflow */
 			case RTL_GIGA_MAC_VER_11:
-			case RTL_GIGA_MAC_VER_22:
 			case RTL_GIGA_MAC_VER_26:
 				netif_stop_queue(dev);
 				rtl8169_tx_timeout(dev);
 				goto done;
 			/* Testers needed. */
+			case RTL_GIGA_MAC_VER_22:
+				for (i = 0; i < 4000000; i++) {
+					if (RTL_R16(IntrStatus) & RxFIFOEmpty) {
+						RTL_W16(IntrStatus, RxFIFOOver);
+						printk(KERN_INFO "FEmp %d\n", i);
+						break;
+					}
+					udelay(10);
+				}
+				if (i >= 4000000)
+					printk(KERN_ERR "no FEmp\n");
 			case RTL_GIGA_MAC_VER_17:
 			case RTL_GIGA_MAC_VER_19:
 			case RTL_GIGA_MAC_VER_20:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/