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 <jwoi...@atrad.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
