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: <4ED538EC.4010509@wolke7.net>
Date:	Tue, 29 Nov 2011 20:56:28 +0100
From:	booster@...ke7.net
To:	Francois Romieu <romieu@...zoreil.com>
CC:	hayeswang <hayeswang@...ltek.com>,
	'Jonathan Nieder' <jrnieder@...il.com>,
	'Eric Dumazet' <eric.dumazet@...il.com>,
	netdev@...r.kernel.org, 'nic_swsd' <nic_swsd@...ltek.com>,
	linux-kernel@...r.kernel.org,
	'Armin Kazmi' <armin.kazmi@...dortmund.de>
Subject: Re: [bug?] r8169: hangs under heavy load

Francois Romieu wrote:
> hayeswang <hayeswang@...ltek.com> :
> [...]
>   
>> For the 8168c and the later chips, our hardware engineer says that don't enable
>> the RxFIFOOver of IntrMask and don't clear the RxFIFOOver of IntrStatus. The
>> hardware will automatically escape Rx fifo full situation. Although you try to
>> clear the RxFIFOOver of IntrStatus, maybe the bit wouldn't be cleared. Just
>> disregard it.
>>     
>
> Should "later" be understood as gigabit PCI-E only or is there a similar
> difference of behavior between older fast-ethernet PCI-E and more recent
> ones ?
>
> Gerd, can you try the patch below ? It should match Haye's description.
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 6f06aa1..97b5593 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -4885,8 +4885,7 @@ static void rtl_hw_start_8168(struct net_device *dev)
>  	RTL_W16(IntrMitigate, 0x5151);
>  
>  	/* Work around for RxFIFO overflow. */
> -	if (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
> -	    tp->mac_version == RTL_GIGA_MAC_VER_22) {
> +	if (tp->mac_version == RTL_GIGA_MAC_VER_11) {
>  		tp->intr_event |= RxFIFOOver | PCSTimeout;
>  		tp->intr_event &= ~RxOverflow;
>  	}
> @@ -5804,6 +5803,10 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
>  	 */
>  	status = RTL_R16(IntrStatus);
>  	while (status && status != 0xffff) {
> +		status &= ~tp->intr_event;
> +		if (!status)
> +			break;
> +
>  		handled = 1;
>  
>  		/* Handle all of the error cases first. These will reset
> @@ -5818,7 +5821,6 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
>  			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);
> @@ -5828,6 +5830,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
>  			case RTL_GIGA_MAC_VER_19:
>  			case RTL_GIGA_MAC_VER_20:
>  			case RTL_GIGA_MAC_VER_21:
> +			case RTL_GIGA_MAC_VER_22:
>  			case RTL_GIGA_MAC_VER_23:
>  			case RTL_GIGA_MAC_VER_24:
>  			case RTL_GIGA_MAC_VER_27:
>
>   
Hi Francois, now an ifconfig shows the eth0 interface is up, but no data
is transfered
and a ping is not working.
[   14.522369] r8169 0000:02:00.0: eth0: link down
[   14.522773] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   14.671742] r8169 0000:03:00.0: eth1: link down
[   14.672169] ADDRCONF(NETDEV_UP): eth1: link is not ready
An added output shows that it is really detected as RTL_GIGA_MAC_VER_22.

Any more ideas ?


View attachment "dmesg_20111129_kernel_3.2_r8169-patch2.txt" of type "text/plain" (45195 bytes)