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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 26 May 2008 22:54:53 +0200
From:	Jesper Krogh <jesper@...gh.cc>
To:	David Miller <davem@...emloft.net>
CC:	yhlu.kernel@...il.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, matheos.worku@....com
Subject: Re: NIU - Sun Neptune 10g - Transmit timed out reset (2.6.24)

David Miller wrote:
> From: David Miller <davem@...emloft.net>
> Date: Mon, 26 May 2008 12:33:38 -0700 (PDT)
> 
>> From: Jesper Krogh <jesper@...gh.cc>
>> Date: Mon, 26 May 2008 21:03:34 +0200
>>
>>> Ok. Now I also hit it in production with the NFS-server, so this
>>> is definately a real bug somewhere in the driver. Should I register it
>>> at bugzilla?
>> Please feel free to do that.
> 
> BTW, I did stare at some of the transmit code of the NIU driver
> while flying from Tokyo to Seattle a few hours ago, and I
> found one possible theory on the transmit timeouts.
> 
> Can you try the patch below and let us know if the symptoms
> continue?
> 
> [ Note to Matheos: The IRQ marking scheme of the NIU doesn't mesh
>   well with how things work under Linux.  We really needs a
>   "TX queue empty" interrupt status in order to handle all cases
>   properly.  Otherwise we really cannot decide not mark some TX
>   descriptors without potentially entering a deadlock condition.  ]
> 
> diff --git a/drivers/net/niu.c b/drivers/net/niu.c
> index 918f802..7ab7f8e 100644
> --- a/drivers/net/niu.c
> +++ b/drivers/net/niu.c
> @@ -6165,7 +6165,7 @@ static int niu_start_xmit(struct sk_buff *skb, struct net_device *dev)
>  	rp->tx_buffs[prod].mapping = mapping;
>  
>  	mrk = TX_DESC_SOP;
> -	if (++rp->mark_counter == rp->mark_freq) {
> +	if (1 /*++rp->mark_counter == rp->mark_freq*/) {
>  		rp->mark_counter = 0;
>  		mrk |= TX_DESC_MARK;
>  		rp->mark_pending++;

Applied and running.. I've now pushed 400GB of data through it trying to
get it to hit the bug but it is still running.

So without saying that it solved the problem, it definately seems so.
2.6.26-rc4 + above patch.

Jesper
-- 
Jesper
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists