netdev - Re: NIU - Sun Neptune 10g - Transmit timed out reset (2.6.24)

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] [day] [month] [year] [list]

Message-Id: <20080617.170226.132179445.davem@davemloft.net>
Date:	Tue, 17 Jun 2008 17:02:26 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	Matheos.Worku@....COM
Cc:	jesper@...gh.cc, yhlu.kernel@...il.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: NIU - Sun Neptune 10g - Transmit timed out reset (2.6.24)

From: Matheos Worku <Matheos.Worku@....COM>
Date: Tue, 27 May 2008 18:18:57 -0700

> Considering that fixing the HW would take considerable time, I was 
> wondering if the scheme we use in the nxge driver could be considered as 
> a workaround. Since the niu driver is already doing skb_orphan as a work 
> around, what if  already transmitted TX buffers are  reclaimed 
> periodically, within dev->hard_start_xmit() ?  Then TX_DESC_MARK would 
> be set if/when available TX descriptor count falls below some watermark. 
> Disable device TX queue about the time  TX_DESC_MARK is set and enable 
> it within TX interrupt.

This is still insufficient.

Even if we detach the socket association, there are still resources
held by the SKB, such as firewalling state.

So you can get into situations where, for example, you can't unload
netfilter modules, attempts just hang the system.

The only workaround is to use a timer to purge the TX queue, and that's
far from acceptable in my opinion, because of the timer maintainence
overhead and the latency.

--
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