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]
Date:	Wed, 18 May 2016 16:21:37 +0930
From:	Jonathan Woithe <jwoithe@...ad.com.au>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	netdev@...r.kernel.org
Subject: Re: r8169 regression: UDP packets dropped intermittantly

On Thu, Apr 07, 2016 at 12:14:18PM +0930, Jonathan Woithe wrote:
> On Mon, Feb 08, 2016 at 01:03:19PM +1030, Jonathan Woithe wrote:
> > On Wed, Dec 02, 2015 at 12:58:52AM +0100, Francois Romieu wrote:
> > > Jonathan Woithe <jwoithe@...ad.com.au> :
> > > [...]
> > > > Any thoughts or progress at this stage?  Are there further tests you need me
> > > > to do ?
> > > 
> > > Yes but you should expect two more days without signal.
> > 
> > FYI I am now back from annual leave and linux.conf.au.  This means I am in
> > a position to test possible solutions to this problem once you are able to
> > make them available.
> 
> Has there been any further progress on this problem?  I still have access to
> the hardware and systems if further tests are required.

To assist in picking up this issue I thought I'd summarise where things are
at from my perspective.

The problem is that small low-speed UDP packets are being dropped by the
r8169-based network card in our systems.  Git bisect showed that the
regression started with commit da78dbff2e05630921c551dbbc70a4b7981a8fff.

On 23 Nov 2015 Francois Romieu requested:

> If you can crash your system at will, you may apply the patch below to
> da78dbff2e05630921c551dbbc70a4b7981a8fff ("r8169: remove work from irq
> handler.") parent (aka 1e874e041fc7c222cbd85b20c4406070be1f687a) and
> build it in a current tree (say 4.2).

I did this (in a 4.3 tree) and the regression was resolved.  Following the
communuication on 2 Dec 2015 indicating there would be further news in a
couple of days, I haven't head anything else on the subject.

I am keen to resolve this problem as soon as possible as it will allow us to
move systems away from the ancient 2.6 kernel we are currently forced to use
as a result of this UDP regression (changing the network card for something
based on another chipset is not an option).  If there are further tests
needed to progress a fix please let me know as I still have an offline
system I can use for testing.

Regards
  jonathan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ